System and method for managing vehicle dispatch and fleet workflow

ABSTRACT

A system and method for processing GPS event data and providing an interface for managing fleet and vehicle workflows.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to pending U.S. provisional patentapplication No. 61/639,426, filed Apr. 27, 2012, and titled “SYSTEM ANDMETHOD FOR TRACKING DRIVER HOURS AND TIMEKEEPING,” the entirety of whichis incorporated herein by reference.

DESCRIPTION OF RELATED ART

It is known to provide an on-board unit which uses technology such asGPS (Global Positioning System) to monitor a vehicle's positions andtransmit wireless uploads to a central host system as well as manage ofincoming data traffic without data losses or corruption and/or withoutdatabase record locking: Such a unit may also upload vehicle statusevents such as engine fault events. GB2345824 and U.S. Pat. No.7,388,518 describes such systems and methods therefor, the entirety ofeach of which are incorporated by reference herein.

SUMMARY OF THE INVENTION

Described are embodiments of method and a computer system fordispatching jobs to a vehicle fleet including at least one computerprocessor and computer readable storage medium or media includingcomputer code and at least one storage device, the system comprising: amemory including a database configured to store at least one record of ajob associated with a fleet entity; the one or more processorsprogrammed perform at least one of: receive GPS event data transmittedfrom at least one GPS device, each GPS device associated with a vehicle,the event GPS event data including location information for the vehicle;associate at least one vehicle with the job based on the GPS event data;and provide, for a graphic user interface, an indication of the at leastone vehicle to dispatch the job.

The computer system of can comprise one or more processors furtherprogrammed at least to provide, for the graphic user interface, theindication of the at least one vehicle in conjunction with a map showingthe position of the vehicle.

The computer system of can comprise one or more processors furtherprogrammed at least to provide for the graphic user interface, at leastone input interface for selecting an action for dispatching the job. Theaction can include at least one of: assigning the job to a driver orvehicle, finding a nearest vehicle to a job; reassigning the job to adriver or vehicle; recalling the job; identifying the job as complete;reopening the job; and canceling the job. The computer system of cancomprise one or more processors further programmed at least to provide,for the graphic user interface, a pop-up display for selecting thenearest driver.

The computer system of can comprise one or more processors furtherprogrammed at least to provide for the graphic user interface, a displayof at least one criterion for finding the nearest vehicle. The at leastone criterion for finding the nearest vehicle can include at least oneof a time criterion and a group criterion.

The computer system of can comprise one or more processors furtherprogrammed at least to provide for the graphic user interface, a displayat least one of, for at least one nearest vehicle to a job: a number ofthe nearest vehicles an identification of a driver associated eachvehicle; a distance of the vehicle from the job; a travel time for thejob; and contact information for the vehicle or driver. The contactinformation can include at least one of an indicator showing the driverhas a computer application configured to interface with the graphic userinterface.

The computer system of can comprise one or more processors furtherprogrammed at least to provide, for the graphic user interface, anassignment action input for assigning the job to the driver via theapplication.

The computer system of can comprise one or more processors furtherprogrammed at least to provide an interface tool for at least one of:managing a job type; creating a new job; managing customers for a job;uploading a job; and editing a job.

Described are embodiments of method and a computer system for methodcomprising, in at least one computer and a computer readable storagemedium or media including computer code: receiving GPS event datatransmitted from a plurality of GPS devices, each GPS device associatedwith a vehicle; associating at least one vehicle with the job based onthe GPS event data; and providing, for a graphic user interface, anindication of the at least one vehicle to dispatch the job. The methodcan comprise providing, for the graphic user interface, the indicationof the at least one vehicle in conjunction with a map showing theposition of the vehicle providing, for the graphic user interface, atleast one input interface for selecting an action for dispatching thejob. The action can include at least one of: assigning the job to adriver or vehicle; finding a nearest vehicle to a job; reassigning thejob to a driver or vehicle; recalling the job; identifying the job ascomplete; reopening the job; and canceling the job.

The method can further comprise providing, for the graphic userinterface, display of at least one criterion for finding the nearestvehicle. The at least one criterion for finding the nearest vehicle caninclude at least one of: a time criterion and a group criterion.

The method can further comprise providing, for the graphic userinterface, a display of at least one of, for at least one nearestvehicle to a job: a number of the nearest vehicles; an identification ofa driver associated each vehicle; a distance of the vehicle from thejob; a travel time for the job; and contact information for the vehicleor driver. The contact information can include at least one of: anindicator showing the driver has a computer application configured tointerface with the graphic user interface.

The method can further comprise providing for the graphic userinterface, an assignment action input for assigning the job to thedriver via the application.

The method can further comprise providing, for the graphic userinterface, a pop-up display for selecting the nearest driver.

The method can further comprise providing, for the graphic userinterface, a display of at least one of: a job identification; anaddress for the job; and a job status dropdown.

The method can further comprise providing, for the graphic userinterface, the indication of at least one nearest vehicle in conjunctionwith a map showing the position of the at least on nearest vehicle.

The method can further comprise providing, for the graphic userinterface, a display of a schedule for at least one job and at least onedriver.

The method can further comprise providing an interface tool for at leastone of: managing a job type; creating a new job; managing customers fora job; uploading a job; and editing a job.

Throughout the specification and claims, the following terms take atleast the meanings explicitly associated herein, unless the contextdictates otherwise. The meanings identified below do not necessarilylimit the terms, but merely provide illustrative examples for the terms.The phrase “an embodiment” as used herein does not necessarily refer tothe same embodiment, though it may. In addition, the meaning of “a,”“an,” and “the” include plural references; thus, for example, “anembodiment” is not limited to a single embodiment but refers to one ormore embodiments. Similarly, the phrase “one embodiment” does notnecessarily refer the same embodiment and is not limited to a singleembodiment. As used herein, the term “or” is an inclusive “or” operator,and is equivalent to the term “and/or,” unless the context clearlydictates otherwise.

It is noted that in this disclosure and particularly in the claimsand/or paragraphs, terms such as “comprises,” “comprised,” “comprising,”and the like can have the meaning attributed to it in U.S. patent law;that is, they can mean “includes,” “included,” “including,” “including,but not limited to” and the like, and allow for elements not explicitlyrecited. Terms such as “consisting essentially of” and “consistsessentially of” have the meaning ascribed to them in U.S. patent law;that is, they allow for elements not explicitly recited, but excludeelements that are found in the prior art or that affect a basic or novelcharacteristic of the invention. Embodiments of the present inventionare disclosed or are apparent from and encompassed by, the followingdescription.

It will be appreciated by those skilled in the art that the foregoingbrief description and the following detailed description are exemplary(i.e., illustrative) and explanatory of the present invention, but arenot intended to be restrictive thereof or limiting of the advantageswhich can be achieved by this invention in various implementations.Additionally, it is understood that the foregoing summary and ensuingdetailed description are representative of some embodiments of theinvention, and are neither representative nor inclusive of all subjectmatter and embodiments within the scope of the present invention. Thus,the accompanying drawings, referred to herein and constituting a parthereof, illustrate embodiments of this invention, and, together with thedetailed description, serve to explain principles of embodiments of theinvention.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments are illustrated in the figures of the accompanying drawings,which are meant to be exemplary and not limiting, and in which likereferences are intended to refer to like or corresponding things.

FIGS. 1A-1D are block diagrams of a representative computer system.

FIG. 2 depicts a representative GPS system.

FIGS. 3A-3K depict an exemplary representations of pages for graphicuser interface.

FIGS. 4A-4F depict exemplary representations of dispatch pages forgraphic user interface.

FIG. 5 depicts an exemplary representation of a page for finding nearestvehicles for graphic user interface.

FIG. 6 depicts an exemplary representation of a page for managing jobtypes for graphic user interface.

FIG. 7 depicts an exemplary representation of a page for creating jobsfor graphic user interface.

FIGS. 8A-8B depict exemplary representations of pages for creating orsearching for customers and creating jobs for a graphic user interface.

FIGS. 9A-9B depict exemplary representations of a page for editing a jobfor a graphic user interface.

FIG. 10 depicts exemplary representations of a page for managingcustomers for a graphic user interface.

FIGS. 11A to 11D depict exemplary representations of pages for TimecardReports for a Graphic User interface.

FIGS. 12A-12C are an exemplary flow showing GPS event data analysis.

DETAILED DESCRIPTION OF THE EMBODIMENTS

It is to be understood that the figures and descriptions of the presentinvention have been simplified to illustrate elements that are relevantfor a clear understanding of the present invention, while eliminating,for purposes of clarity, many other elements which are conventional inthis art. Those of ordinary skill in the art will recognize that otherelements are desirable for implementing the present invention. However,because such elements are well known in the art, and because they do notfacilitate a better understanding of the present invention, a discussionof such elements is not provided herein.

The use of the terms “a,” “an,” “at least one,” “one or more,” andsimilar terms indicate one of a feature or element as well as more thanone of a feature. The use of the term “the” to refer to the feature doesnot imply only one of the feature and element.

When an ordinal number (such as “first,” “second,” “third,” and so on)is used as an adjective before a term, that ordinal number is used(unless expressly or clearly specified otherwise) merely to indicate aparticular feature, such as to distinguish that particular feature fromanother feature that is described by the same term or by a similar term.

When a single device, article or other product is described herein, morethan one device/article (whether or not they cooperate) mayalternatively be used in place of the single device/article that isdescribed. Accordingly, the functionality that is described as beingpossessed by a device may alternatively be possessed by more than onedevice/article (whether or not they cooperate). Similarly, where morethan one device, article or other product is described herein (whetheror not they cooperate), a single device/article may alternatively beused in place of the more than one device or article that is described.Accordingly, the various functionality that is described as beingpossessed by more than one device or article may alternatively bepossessed by a single device/article.

The functionality and/or the features of a single device that isdescribed may be alternatively embodied by one or more other deviceswhich are described but are not explicitly described as having suchfunctionality/features. Thus, other embodiments need not include thedescribed device itself, but rather can include the one or more otherdevices which would, in those other embodiments, have suchfunctionality/features.

The present invention will now be described in detail on the basis ofexemplary embodiments. The invention disclosed herein may be practicedusing programmable digital computers and networks therefor.

As shown in FIGS. 1A-1B, disclosed is a system 100, which includes acomputer 140 containing a processor 145, memory 157 and other componentstypically present in general purpose computers.

FIG. 1A is a block diagram of a representative computer. The computersystem 140 includes at least one processor 145, such as an Intel Core™or Xeon™ series microprocessor or a Freescale™ PowerPC™ microprocessor,coupled to a communications channel 147. The computer system 140 furtherincludes an input device 149 such as, e.g., a keyboard or mouse, anoutput device 151 such as, a CRT or LCD display, a communicationsinterface 153, a data storage device 155 such as a magnetic disk or anoptical disk, and memory 157 such as Random-Access Memory (RAM), eachcoupled to the communications channel 147. The communications interface153 may be coupled to a network such as the Internet.

Memory 157 stores information accessible by processor 145, includinginstructions that may be executed by the processor 145. It also includesdata that may be retrieved, manipulated or stored by the processor. Thememory may be of any type capable of storing information accessible bythe processor, such as a hard-drive, memory card, ROM, RAM, DVD, CD-ROM,write-capable, and read-only memories. The processor 145 may be anywell-known processor, such as processors from Intel Corporation or AMD.Alternatively, the processor may be a dedicated controller such as anASIC.

The instructions may be any set of instructions to be executed directly(such as machine code) or indirectly (such as scripts) by the processor.In that regard, the terms “instructions,” “steps” and “programs” may beused interchangeably herein. The instructions may be stored in objectcode format for direct processing by the processor, or in any othercomputer language including scripts or collections of independent sourcecode modules that are interpreted on demand or compiled in advance.Functions, methods and routines of the instructions are explained inmore detail below.

One skilled in the art will recognize that, although the data storagedevice 155 and memory 157 are depicted as different units, the datastorage device 155 and memory 157 can be parts of the same unit orunits, and that the functions of one can be shared in whole or in partby the other, e.g., as RAM disks, virtual memory, etc. It will also beappreciated that any particular computer may have multiple components ofa given type, e.g., processors 145, input devices 149, communicationsinterfaces 153, etc.

The data storage device 155 and/or memory 157 may store an operatingsystem 160 such as Microsoft Windows 7®, Windows XP® or Vista™, Linux®,Mac OS®, or Unix®. Other programs 162 may be stored instead of or inaddition to the operating system. It will be appreciated that a computersystem may also be implemented on platforms and operating systems otherthan those mentioned. Any operating system 160 or other program 162, orany part of either, may be written using one or more programminglanguages such as, e.g., Java®, C, C++, C#, Visual Basic®, VB.NET®,Perl, Ruby, Python, or other programming languages, possibly usingobject oriented design and/or coding techniques.

Data may be retrieved, stored or modified by processor 145 in accordancewith the instructions. For instance, although the system and method isnot limited by any particular data structure, the data may be stored incomputer registers, in a relational database as a table having aplurality of different fields and records, XML documents, or flat files.The data may also be formatted in any computer-readable format such as,but not limited to, binary values, ASCII or Unicode. By further way ofexample only, image data may be stored as bitmaps comprised of pixelsthat are stored in compressed or uncompressed, or lossless or lossyformats (e.g., JPEG), vector-based formats (e.g., SVG) or computerinstructions for drawing graphics. Moreover, the data may comprise anyinformation sufficient to identify the relevant information, such asnumbers, descriptive text, proprietary codes, pointers, references todata stored in other memories (including other network locations) orinformation that is used by a function to calculate the relevant data.

It will be understood by those of ordinary skill in the art that theprocessor and memory may actually comprise multiple processors andmemories that may or may not be stored within the same physical housing.For example, some of the instructions and data may be stored onremovable CD-ROM and others within a read-only computer chip. Some orall of the instructions and data may be stored in a location physicallyremote from, yet still accessible by, the processor. Similarly, theprocessor may actually comprise a collection of processors which may ormay not operate in parallel.

One skilled in the art will recognize that the computer system 140 mayalso include additional components and/or systems, such as networkconnections, additional memory, additional processors, networkinterfaces, input/output busses, for example. One skilled in the artwill also recognize that the programs and data may be received by andstored in the system in alternative ways. For example, acomputer-readable storage medium (CRSM) reader 164, such as, e.g., amagnetic disk drive, magneto-optical drive, optical disk drive, or flashdrive, may be coupled to the communications bus 147 for reading from acomputer-readable storage medium (CRSM) 166 such as, e.g., a magneticdisk, a magneto-optical disk, an optical disk, or flash RAM.Accordingly, the computer system 140 may receive programs and/or datavia the CRSM reader 164. Further, it will be appreciated that the term“memory” herein is intended to include various types of suitable datastorage media, whether permanent or temporary, including among otherthings the data storage device 155, the memory 157, and the CSRM 166.

Two or more computer systems 140 may be connected, e.g., in one or morenetworks, via, e.g., their respective communications interfaces 155and/or network interfaces (not depicted).

A computer system network is shown in FIG. 1B. A network 182 may, forexample, connect one or more workstations 184 with each other and withother computer systems, such as file servers 186 or mail servers 188.The connection may be achieved tangibly, e.g., via Ethernet® or opticalcables, or wirelessly, e.g., through use of modulated microwave signalsaccording to the IEEE 802.11 family of standards. A computer system thatparticipates in the network may send data to another computer system inthe network via the network connection.

One use of a network 180 is to enable a computer system to provideservices to other computer systems, consume services provided by othercomputer systems, or both. For example, a file server 186 may providecommon storage of files for one or more of the workstations 190 on anetwork 182. A workstation 190 sends data including a request for a fileto the file server 186 via the network 182 and the file server 186 mayrespond by sending the data from the file back to the requestingworkstation 190.

As will be recognized by those skilled in the relevant art, the terms“workstation,” “client,” and “server” are used herein to describe acomputer's function in a particular context. A workstation may, forexample, be a computer that one or more users work with directly, e.g.,through a keyboard and monitor directly coupled to the computer system.A computer system that requests a service through a network is oftenreferred to as a client, and a computer system that provides a serviceis often referred to as a server. But any particular workstation may beindistinguishable in its hardware, configuration, operating system,and/or other software from a client, server, or both.

In one aspect, computer 204 is a server communicating with one or moreclient computers 184,192. For example, computer 204 may be a web serveror a hub and data storage service. Each client computer may beconfigured similarly to the server 184, 192, with a processor, memoryand instructions 240. Each client computer 184, 192 may be a personalcomputer, intended for use by a person, having all the internalcomponents normally found in a personal computer such as a centralprocessing unit (CPU), display device 151 (for example, a monitor havinga screen, a projector, a touch-screen, a small LCD screen, a television,or another device such as an electrical device that is operable todisplay information processed by the processor), CD-ROM, hard-drive,user input 149 (for example, a mouse, keyboard, touch-screen ormicrophone), speakers, modem and/or network interface device (telephone,cable or otherwise) and all of the components used for connecting theseelements to one another. Moreover, computers in accordance with thesystems and methods described herein may comprise any device capable ofprocessing instructions and transmitting data to and from humans andother computers including general purpose computers, PDAs, networkcomputers lacking local storage capability, and set-top boxes fortelevisions.

Although the client computers 184, 192 may comprise a full-sizedpersonal computer, the system and method may also be used in connectionwith mobile devices capable of wirelessly exchanging data with a serverover a network such as the Internet. For example, client computer1184,192 may be a wireless-enabled FDA such as an iPhone, and Androidenabled smart phone, a Blackberry phone, or another Internet-capablecellular phone. In either regard, the user may input information using asmall keyboard (in the case of a Blackberry phone), a keypad in the caseof a typical cell phone), a touch screen (in the case of a FDA and/orsmart phone) or any other means of user input.

Client computers 184, 192 may include a component, such as circuits, todetermine the geographic location of the device. For example, mobiledevice may include a GPS receiver. By way of further example, thecomponent may include software for determining the position of thedevice based on other signals received at the mobile device, such assignals received at a cell phone's antenna from one or more cell phonetowers if the mobile device is a cell phone.

Servers 186, 188, 202, 204 and client computers 184 and 192 are capableof direct and indirect communication, such as over a network 180, 200.Although only a few computers are depicted in FIGS. 1A-1B, it should beappreciated that a typical system can include a large number ofconnected computers, with each different computer being at a differentnode of the network 200. The network, and intervening nodes, maycomprise various configurations and protocols including the Internet,World Wide Web, intranets, virtual private networks, wide area networks,local networks, private networks using communication protocolsproprietary to one or more companies, Ethernet, WiFi and HTTP, andvarious combinations of the foregoing. Such communication may befacilitated by any device capable of transmitting data to and from othercomputers, such as modems (e.g., dial-up, cable or fiber optic) andwireless interfaces.

Although certain advantages are obtained when information is transmittedor received as noted above, other aspects of the system and method arenot limited to any particular manner of transmission of information. Forexample, in some aspects, information may be sent via a medium such as adisk, tape or CD-ROM. In other aspects, the information may betransmitted in a non-electronic format and manually entered into thesystem. Yet further, although some functions are indicated as takingplace on a server and others on a client, various aspects of the systemand method may be implemented by a single computer having a singleprocessor.

A network 182 may be connected to one or more other networks 180, e.g.,via a router 196. A router 196 may also act as a firewall, monitoringand/or restricting the flow of data to and/or from a network 180 asconfigured to protect the network. A firewall may alternatively be aseparate device (not pictured) from the router 196

A network of networks 180 may be referred to as an internet. The term“the Internet” 200 refers to the worldwide network of interconnected,packet-switched data networks that uses the Internet Protocol (IP) toroute and transfer data. A client and server on different networks maycommunicate via the Internet 200. For example, a workstation 190 mayrequest a World Wide Web document from a Web Server 202. The Web Server202 may process the request and pass it to, e.g., an Application Server204. The Application Server 204 may then conduct further processing,which may include, for example, sending data to and/or receiving datafrom one or more other data sources. Such a data source may include,e.g., other servers on the same network.

For example in one embodiment, an on-board GPS unit uploads information(eg. via a hub 153) about a vehicle v1, v2 . . . vn to a central hostsystem 208. Information about the vehicle derived from the GPSinformation can be presented to a user on a display device 151, forexample, as a layout shown in FIG. 2.

In one embodiment, the system is programmed at least to receive GPS evendata recorded by a GPS (Global Positioning System) device, for example,using an on-board unit which uses technology such as GPS to monitor avehicle's positions and transmit wireless uploads to a central hostsystem. Commercially available on-board unit GPS (Global PositioningSystem) devices include those provided by Garmin®, TomTom®, andMagellan®. Referring to FIG. 2 a vehicle tracking system compriseson-board units 1 in vehicles v1, v2, v3 . . . vn, which communicatewirelessly via mobile networks 2 to gateways 3. In this diagram twowireless protocols are indicated, namely GPRS and SMS. However there aretypically a variety of additional protocols. The gateways 3 communicateusing protocols such as UDP and TCP via the Internet 4 with a hostsystem 7 having receivers 5 which are operating system services, and adata storage system 6. The incoming data is written from the receivers 5to the data storage system 6, which includes a communication hub 153 anddatabase 208. GB2345824 and U.S. Pat. No. 7,388,518 describes suchsystems and methods therefor, the entirety of each of which areincorporated by reference herein.

FIG. 1C is a block diagram of a host system 7 showing an exemplarysystem configuration for a host system 7. As shown therein, acommunications layer 153 is operable to receive incoming GPS data andwrite data from the receivers 5 to the data storage system 208. The datastorage system can be divided into any number of databases and logicallayers for data analysis and storage. For example, a messaging layer 208b can be configured to store GPS event data from GPS on-board units 1 ina GPS event database 211. A separated routing database 212 could beprovided to store mapping and route data based on, inter alia, GPS datato store routes traveled by vehicles. Another database layer 208 a caninclude a business logic database 204 and a reporting database 210 tostore rules for analysis of data and reports analyzed data respectively.Another database layer can include at least one database including jobdata or vehicle dispatch data for a vehicle fleet. For instance, one ormore job databases can include job data comprising, for example, jobtypes, drivers associated with vehicles, customer data, and other typesof dispatch data as described herein.

A database layer 208 b can be operably connected to other databases, forexample external databases 204. For example the system can beoperatively connected to at least one speed database including speeddata or traffic data. For instance, one or more speed databases caninclude speed data comprising, for example, a record of a posted speedlimit for a route and/or a record of an average traffic/road speed for aroute.

For example, an external database 204 can provide traffic data whichshows congestion along routes to be traveled by a vehicle, which can beused in conjunction with GPS data 211 and business logic 204 to reroutevehicles or create reports as to congested routes. An applications layer204, such as an application sever 204, can be used to run applicationsprocessing, which may include, for example, sending data to and/orreceiving data from one or more other data sources such as clientworkstations 184, 190, as described above. For example the applicationlayer 204 can be used to provide a graphic user interface 151 of aclient workstation 184,194 a user-interactive interface.

In another example an external database 204 can provide speed and ortraffic data which records data for posted speed limits along routes, orcollects and stores data for average traffic speeds along routes.Exemplary databases include, for example, the TeleAtlas™ speed limitdata, or Infix™ average speed data. This data can be used in conjunctionwith GPS data 211 and business logic 204 to show speed violations ofvehicles and drivers, compare average speeds of a driver's and/or afleet's average traffic/road speed, and track performance and createalerts as described herein.

An applications layer 204, such as an application sever 204, can be usedto run applications processing, which may include, for example, sendingdata to and/or receiving data from one or more other data sources suchas client workstations 184, 190, as described above. For example theapplication layer 204 can be used to provide a graphic user interface151 of a client workstation 184,194 a user-interactive interface.

The client terminal 184,194 may include any computing terminal, such asa personal computer, a handheld device, or any other currently existingor later developed computing terminals. Further, it should be understoodthat the client terminal 184,194 may connect to the gateway(s) 3 viawireless communication sinks, wireline communication links, or acombination thereof, as described herein. In general, according to theexample embodiments described herein, the client terminal 184,194 is acomputer that allows a user such as a fleet manager or dispatcher toactively manage a fleets of vehicles and drivers therefor, and usessoftware that creates specialized fleet management screens on the clientterminal. The range and quality of features available to the fleetmanager on his or her client terminal's screen may vary according to thespecific software application being run on the client terminal 106.Among other functional features, a fleet management screen being run onthe client terminal 106 may enable fleet managers to, inter alia, viewand manage vehicles and drivers therefor orders, view and edit alertsand exceptions, and monitor fleet and vehicle performance and activity.However, it should be understood that, in addition to interactivetrading screens, the client terminal 184, 194 may also run automatednon-interactive types of trading applications.

A commercially available application that allows fleet owner to manageand direct fleet activity and performance like embodiments described isFleetMatics GPS fleet tracking. However, the preferred embodiments arenot limited to any particular product that performs translation, storageand display functions.

In one embodiment, a system is configured to received, store, andprocess GPS data to provide to a graphic user interface of a client auser-interactive interface for tracking and reporting on vehicles andvehicle fleets. For each vehicle, GPS event data is stored for over anoperation period. For example, the data can be stored and processed toshow event data for at least one vehicle v for an operation period of aworkday, a week, a month, a quarter, a year, the life of a servicecontract, or any desirable time period. The GPS event data can then beanalyzed to derive a plurality of operational metrics for each vehicle.Exemplary operational metrics that can be derived from GPS data include:engine on/off, vehicle mileage, idling, number of stops, distancetravelled, and speed (including high speed and average speed). Forexample, an on-board GPS device can be configured to be operational totransmit when a vehicle engine is on, thus engine on/off time can bederived. Idling (stopped while engine running) and speeding(distance/time), as well as vehicle mileage can also be derived fromtracking via GPS. This data in turn can be used to derive a number ofother operational metrics, including vehicle activity over apredetermined time period, vehicle operational reports, employeeperformance (e.g., working hours, deliveries per day), driver behavior(e.g.: speeding violations, idling over limits); and fleet performance(e.g., metrics based on data above derived for multiple vehicles).Accordingly any number of operational metrics can be derived from GPSdata, either alone or in conjunction with data from other databases,including number of stops per vehicle, performance against a criterion,employee performance; driver behavior; and fleet performance, speedingseverity, a speeding violation, average vehicle speed, vehicle speedversus a posted speed limit, vehicle speed versus a speed threshold, andan average road speed for a fleet or driver speed for a route versusaverage road/traffic speed for a route. A graphic user interface can beconfigured to display including a representation of at least oneoperational metric for each of a plurality of vehicles.

Exemplary graphic representations or interfaces 300 for a graphic userinterface for a user is shown in FIGS. 3A-3K. Such interfaces could bein the form of application software for computer and digital devices asdescribed above, or in the form of webpage accessed by a client from atleast one host server, or any combinations thereof as broadly disclosedherein and without limitation. As shown in FIG. 3A, a “Dashboard” 320page gives a user a first interactive screen to view GPS data andoperational metrics. The top of the graphic user interface 300 has, inone embodiment, tabs for “Reports” 320, “Live Fleet,” 332 “RouteReplay,” 324 “Alerts,” 328 Fleet Service,” 330 and “Admn” 332, whichlead to other user interactive displays. Of course any number of tabs orlinks could be configured for the features as described herein, forexample for “Speed” “Trending,” “Score Card,” and/or A “MyFleetmatics”or “My Fleet” page which can include user configurable fleet statisticsand alerts, or can have default statistics personal to a user, or somemix of user configurable and default features and statistics.

For example, in one embodiment a user can select “Live Fleet” 324 usingan input such as a keyboard or a mouse, which would lead to a page withGPS data and mapping software which tracks vehicles v1, v2 . . . vn. Thepage can allow a user such as a dispatcher to, for example, locate anddispatch the closest vehicle to any job site and reroute the nearestvehicle.

The Dashboard 320, as with any other screen, can be configured to offerpreset modules or objects for a user to interact with or view, or in thealternative it can be configured to allow a user to customize theinformation, reports, alerts, etc most important to the user.

As shown in FIG. 3A, the Dashboard 320 screen includes various graphicrepresentations of operational metrics, including reports and alerts, toaid a user in, among other things, vehicle, employee, and fleetmanagement. For example, the operational metrics 302 for individualvehicles include operational metrics such as a engine on/off 302 a,vehicle mileage 302 b, idling, 302 c, and speeding 302 d. Otheroperational metrics could also be shown such as average speed 302 e,number of stops 302 f, speeding severity 302 h, and speeding violations302 i. Such operational metrics are also shown for various fleetconfigurations as described below.

The Dashboard 320 shows at the top of the interface 300 a graphicinformation display for an individual vehicle 301, which can be selectedfrom a drop down menu 301 a. Other methods of selection can be used, forexample, by selecting with a mouse, a graphic for the vehicle v4 (shownas “Van 1006”) in a fleet report graphic 335. The graphic informationdisplay for the vehicle 301 includes a reporting and alerts for thevehicle v4, for example, operational metrics such as at least one engineon/off graphic 302 a, vehicle mileage graphic 302 b, idling graphic 302c, and a speeding graphic 302 d.

As shown, the graphics 302 a, 302 b, 302 c, 302 d on the individualvehicle 301 is shown reporting graphic that shows a rating 303 undereach operational metric comparing the vehicle performance against othervehicles in the fleet for a 24 hour period. For instance, an engineon/off rating graphic 303 a puts the vehicle v4 in 4th place in thefleet, a vehicle mileage rating graphic 303 b puts the vehicle v4 in 6thplace, idling rating graphic at 303 c at 19th place, and a speedingrating graphic 303 d puts the vehicle v4 at 7th place. These markingsfor v4 are also seen in the fleet management graph 335 a, 335 b, 335 cas described below.

The interface 300 also provides, for the graphic user interface, analert when an operational metric for a vehicle exceeds a predeterminedthreshold established for the operational metric. For example, reportgraphic on the individual vehicle 301 shows the name of the driver, thatthe vehicle has shutdown (e.g., for the end of the workday), the timefor shutdown, and for each of the operational metrics, a pie chartgraphic 305 a, 305 b, 305 c, 305 d, and a split-window graphic 306 a/308a, 306 b/308 b, 306 c/308 c, 306 d 8/308 d 8/309 d for the individual'sengine on/off, vehicle mileage, idling, and speeding graphicsrespectively, each of which are designed to alert and report to a userwhen a vehicle has exceeded a predetermined criterion such as apredetermined threshold. Each of the pie chart 330 and split windowgraphics 306/308 show the time the vehicle spent within threshold 306,as well as a representation that alerts when the vehicle exceeded thethreshold. For example, each metric has in the split window graphic306/308 a predetermined criterion or threshold 306 established for the24 hour period: 8 hours for engine on/off 306 a, 150 miles for vehiclemileage 306 b 8/308 b, 1.0 hours for idling 306 c/308 c, and threespeeding thresholds of over 70 mph, 80 mph, and 90 mph under speeding306 d 8/308 d 8/309 d.

For example, the “Engine On/Off” split window 306 a/308 a has in aleft-hand window, for vehicle operation within the predeterminedthreshold 306 a, a graphic which includes a color (green) and textdescribing the vehicle's v4 operation statistic under the threshold, 7hours, 50 m. The right-hand window 308 a, shows a window with the timeremaining in the 24 hour period (16 hours, 10 min.) Because this is timewhere the engine was not running, and thus within the threshold, thewindow 308 a is configured to show neutral color or identifier (e.g.white, tan, clear). The pie chart 305 a shows a visual with green andneutral coloring corresponding to the times in the split window 306a,308 a which allows a user to readily visualize the percentages for theEngine On/Off time.

The “Vehicle Mileage” split window 306 b/308 b shows the predeterminedthreshold of 150 miles in the left-hand window 306 b, which is in greenas with Engine On/Off. However, the right-hand window 308 b shows thedriver has exceeded the threshold by another 38 miles. As this is inexcess of the threshold, where the window 308 b is configured to alertthe user with a red color. The pie chart 305 b shows a visual with greenand red coloring corresponding the times in the split window 306 b, 308b which allows a user to readily visualize the percentages for thevehicle mileage, as well as alert the user that the vehicle is excess ofthe threshold.

The Idling and Speeding graphics are similarly configured, therebyproving a user friendly view for all the metrics for the individualvehicle and driver. For example, Idling 302 c includes an alertingthreshold where of 1 hour, and alerts for excess of an hour of idling.Speeding 302 d includes reporting and alerting for, among other things,speeds in excess of 70 mph 306 d, 80 mph 308 d, and 90 mph 309 d, withdifferent colors for each (e.g. green, yellow, and red).

It will be understood that other graphical displays could be used, suchas bar graphs, gauge icons, whimsical graphics (e.g., a speedometer or astopwatch), or any other such graphic as is useful.

For each vehicle v1, v2, v3 . . . vn, historical GPS event data can bestored, as for example, for a plurality of operation periods.Accordingly, while the graphics 302 a, 302 b, 302 c, 302 d on theindividual vehicle 301 are over an operational 24 hour period, thegraphics could be configured to show data for longer periods and/or aplurality of operational periods, such as a week, a month, a quarter, ayear, or other periods as desired. Other thresholds could be implementedfor each of these periods, as for example, by adding the criteria orthresholds for each operational period, e.g., for Vehicle Mileage 302 b,or an 160 hour threshold for a 4 work-week period (a five day week),where each 24 hour period is 8 hours. Other reports can be generatedbased on the historical event data.

For example, report information can include one or more reports on:vehicle activity over a predetermined time period, speed (including highspeed and average speed), number of stops, idling, vehicle operationalreports, maintenance, employee performance, driver behavior; and fleetperformance.

An exemplary, selectable “Top 10” fleet report 335 shows reports 335 a,335 b, 335 c, 335 d for the top ten vehicles in each of operationalmetrics for a fleet of vehicles: Engine On/Off 335 a, Distance Traveled335 b, Idling Report 335 c, and High Speed Report 335 d. As noted hereinadditional metrics for “Speeding Violations,” 335 i and “SpeedingSeverity” 335 h can be added to the reports relating to speed.Operational metrics for one of the vehicles v4, “Van 1006” is shown atthe top of the graphic user interface 301, and the vehicle rankings asshown for v4 are shown in three of the metrics 335 a, 335 b, and 335 dwhere the vehicle is in the top 10, as described above. While the reportshows the “Top 10,” a selectable drop down menu 308 b allows a user toselect any number of options for reporting (e.g., top 20, 50) andanother drop down menu 310 allows a user to select time periods (e.g. 24hours, 5 days, a month), to obtain ranked vehicle performance for thefleet and vehicles therein.

The “Engine On/Off Report” 335 ranks the vehicles v1 . . . v10 fromhighest to lowest for “Engine On” time over the 24 hours. For example, arow for the top vehicle v1 shows the engine was on for 9 hours and 58minutes and off for 15 hours and 2 minutes. The lowest ranked v10(Vehicle 0435) shows engine operation for 6 hours and 8 minutes, whereasthe off time is 17 hours and 52 minutes. A tillable bar graph shows onand off times, with “on” being green and off being blank or neutral,with the fill line visually showing the percentage of the 24 hourperiod. Text graphics write out the time. The rows of bar graphs foreach vehicle are aligned in a columnar format so as to readily compareeach vehicle's statistics with one another.

The “Distance Traveled” 335 b reports and alerts are consistent withcriteria for the “Vehicle Mileage” 302 b for the individual driverdescribed above, and ranks vehicles within the top 10 of the fleet fromhighest to lowest for distance traveled. A tillable bar graph shows thepredetermined threshold of 150 miles in the left-hand bar graph, whichis in green. However, the left-hand of the bar graph shows, with filllines by percentage, where the driver has exceeded the 150 milesthreshold. The top ranked vehicle of the fleet is in excess of thethreshold by 236 miles, whereas the 10^(th) ranked vehicle (Van 1026) isonly a few miles over A tillable bar graph shows distances times, withthe 150 mile threshold being green any excess mileage being red so as toalert the user, with the fill line visually showing the percentage ofthe 300 mile distance. Text graphics write out mileage at or under 150miles on the left-hand side, and mileage in excess right hand side.Again, rows of the bar graphs for each vehicle are aligned columnarformat so as to readily compare each vehicle's statistics with oneanother. The “Idling” 305 c and “High Speed” 306 d reports graphics aresimilarly configured, thereby proving a user friendly view for all themetrics for the ranked vehicles and drivers in the fleet. For example,“Idling” 335 c includes an alerting threshold of 1 hour, and reports,bar graphs, alerts for excess of an hour of idling. As shown in FIG. 3C,such a Idling report can also be configured in a format for delivery toa PDA or smartphone, which shows bar graphs, rankings, and idling timesfor a plurality of drivers/vehicles over a 24 hour period. Returning toFIG. 3B, as with the individual report 302 above, speeding 335 dincludes bar graphs, reporting and alerting for, among other things,speed in excess of 70 mph, 80 mph, and 90 mph, with different colors foreach (e.g. green, yellow, and red).

More detailed reports can be created and configured. FIG. 3B shows oneexample of a detailed report for an employee and vehicle, as could beaccessed, for example, in a page for reports (see FIG. 3A 322). Thereport is an “Hours Worked Report” 350 for a vehicle (Truck 18) over afive day workweek, as shown in the lower table 340 portion of thegraphic user interface 340. Each day of the work week is given a row 340a, 340 b, 340 c, 340 d, 340 e on the report, and the table 340 whichincludes columns for day, start time, driver, finish time, and an “HoursWorked” bar graph 344 a, 344 b, 344 c, 344 d, 344 e which shows acolored fill bar and text showing the hours worked. The report hasalerting icons E1, E2, E3, E4, which show exceptions where a vehicle anddriver have exceeded predetermined thresholds or criteria. The exceptionalerts are described in an upper window 342, which can be scrolled usinga scrolling graphic 343 using a mouse, via touch screen, or other input.The upper window 342 reports and alerts the user as to the exceptions,which reports two alerts 306 b, 306 c that on 2 days a driver finishedat 1:22 pm and 1:30 p.m., which is before predetermined time (before4:00 p.m.). Another alert 306 a shows that on one day the driver workedtwo hours longer than a predetermined time period (12 hours), as thedriver worked 14 hours and 33 minutes. By scrolling down the upperwindow module 342, the user can see the fourth alert for the exceptionE4, where the driver exceeded the predetermined threshold of 12 hours by27 minutes. The fill bars on the bar graphs 340 a, 340 b, 340 c, 340 din the lower table 340 can also be colored to reflect an alert, such aswhere on days where a driver has exceeded the predetermined thresholdfor hours worked E1, E4. For example, the fill bar 344 b, 344 e can becolored red when the predetermined threshold is exceeded, whereas whenunder the threshold, the bar 344 a, 344 c, 344 d is colored green. Aweek summary portion 346 of the graphic user interface 350 can give overall statistics for the week, such as start and finish dates and times,total hours and days, and average hours per day.

FIGS. 3D-3E shows another example of a detailed report for an employeeand vehicle, shown as a “Scorecard” for a driver. As shown in FIG. 3D, aleft hand graphic 307 includes tillable bars like those in FIG. 3A thatshow, for a driver, a score card for operational metrics Average Speed302 e, Distance Travelled 302 g, Engine On/Off 302 a, Vehicle Idling 302c, High Speed 302 d, Number of Stops 302 f, and Average Speed 302 e forthe individual driver. A ranking for each metric as compared to othervehicles in the fleet is also given. The GPS data analysis is given fora time period of 5 days. On a right-hand graphic 311, a bar graph shows,for each day of the 5 days, an average speed, where the X-axis has eachday, and the Y-axis shows miles per hour (0-60 mph). FIG. 3E shows ascorecard graphic configured for an application for a PDA such as asmart phone, similar to the left-hand graphic 307, showing a score cardfor operational metrics 302 a, 302 g, 302 c, 302 d, 302 f, 302 e for theindividual driver, as well as a ranking for each metric as compared toother vehicles in the fleet, for a time period of 24 hours.

Still other reports based on GPS data and tracking could be provided,such as driving behavior including vehicle speed, engine start-up andshut-down and idling time, or any others including as described hereinwhich can be used to enforce driving policy and curb unwanted behaviorlike excessive speeding, tardiness and extended vehicle idling.

Similarly, alerts based on GPS data and tracking could be generated suchas alerting a user immediately if a vehicle is used during off-hours,which can indicate a vehicle theft. Other exemplary alerts include latedeliveries, vehicle care or maintenance is needed, or area reportingand/or need for rerouting. For example, alerts can be triggered forexcessive speeding, excessive idling, engine start-up or shut-downduring off-hours unauthorized vehicle usage and when a vehicle enters orexits specific geographic areas. Alerts can also be configured to alertwhen vehicles are due for scheduled maintenance (e.g., based on aspecific length of time, miles driven, or engine-on time). Alerts canalso be segregated from reporting on a separate page of a graphic userinterface (e.g. accessible by a tab 328 as shown on the Dashboard 328 atFIG. 3A).

Alerts can be flagged in relevant reports as shown above, and users canalso be notified of any alerts as soon as a violation occurs via emailor mobile device. As shown in FIG. 3F, it will be noted that in someembodiments, a portable device such as a smart phone or PDA can beconfigured to receive alerts that need urgent attention, such as anoff-hours use alert or an alert indicating rerouting is needed. Forexample, as shown, an application is configured to show a number ofalerts 315 received over a course of time, including for example, alertsshowing a speed criterion or threshold has been met or exceeded. Byselecting one of the alert indicators, a separate details screen 317 isaccessed which describes the alert. Reports or alerts can also beconfigured to show fleet alerts 390 for a fleet trending data 390, asdescribed below.

As explained above, the computer system includes GPS event database. TheGPS event data is analyzed to derive a plurality of operational metricsfor each of a plurality of vehicles; and identify, from the analysis, atleast one trend for a GPS event history using the GPS event data. Thesystem can be configured to provide to a graphic user interface aninteractive display configured display a representation (e.g., a graphicpresentation of the trend). Reports and alerts based on GPS data andtracking and trending is provided, including for driving behaviorincluding vehicle speed (including average speed and high speed), enginestart-up and shut-down, idling time, number of stops or any othersincluding as described herein which can be used to enforce drivingpolicy and curb unwanted behavior like excessive speeding, tardiness andextended vehicle idling.

FIGS. 12A-12C shown a graphic flow for analyzing received GPS event dataand GPS data stored over time to identify, report, and display trending.As shown in FIG. 12A, GPS event data for each vehicle, as describedherein, is gathered over a period of time. The data is analyzed for overtime (shown over 6 months) derive operational metrics 302, for example,mileage 302 b, speeding, 302 d and idling 302 a. Such data can beanalyzed for each month to identify statistics for each operationalmetric, for example, for each vehicle or employee, as well as to derivestatistic for the fleet (e.g. averages under each operational metric, oraverages for defined groups under each metric). Such data can becollected and stored indefinitely.

As shown in FIG. 12B, the analyzed historical event data for eachoperational metric 302 shows trend data 362, for example, theperformance of a vehicle/driver v over the 6 month period, for example,a mileage trend 362 b, a speeding trend, 362 d and an idling trend 362 afor each month. As shown in FIG. 12C, the trend data 362 for eachoperational metric can then be extrapolated from the GPS event data.This trend data is extrapolated for each vehicle in a fleet, as well asfor each employee, and can be used in conjunction with other databasesto provide trending and statistical data as described herein. Trend dataincludes not only the direction in which performance and behavior moveunder operational metrics, but also identifiable changes in thosemovements and comparisons therebetween, as well as statistical datadrawn from GPS data and other databases, as described herein.

FIG. 3G shows one example of a detailed trend report 355 for a fleet andemployees from trending analysis as described above. As shown, a“Trending” page could be accessed, for example, in a page from the“Dashboard.” The trending 355 is an “Average Speed” report 355 for theaverage speed 302 e for at least one fleet group 357 over a time period364, for example 3 months, 6 months, a past year, a selectable year(e.g. 2010, 2011) or “all” (e.g. a full time period for which data wascollected for a given user). It will be noted that the time periodavailable to a given user depends on how much GPS event data stored forthe fleet for that user. For example, a user whose fleet data iscollected starting Jan. 1, 2011 would not have options for data beforethat time.

A drop down menu 359 is configured to allow a user to select any numberof operational metrics 302 as described herein, for example: AverageSpeed 302 e, Distance Travelled 302 g, Engine On/Off 302 a, VehicleIdling 302 c, High Speed 302 d, Number of Stops 302 f, or Average Speed302 e. While a fleet group 357 is shown as “all fleet groups,” a fleetgroup can include any subset of vehicles, and can be configured to allowa user to set up custom groups a fleet. For example, a user may havefleets for different geographical locations (e.g. a Bronx Fleet,Brooklyn Fleet, Queens Fleet, a New Jersey Fleet, a Dublin Fleet etc.)then the groups can be so defined. GPS data can then be filtered andanalysed for this group for vehicles within in the group selected in themanner described above. The system can also be configured to permit auser to view the type of statistical data within the operational metricFor example another drop down menu 364 allows a user to select either“Averages” or “Totals.” The graphs represent can represent either totalsacross the fleet or subset selected, or non-zero averages across thefleet. A non-zero average discounts, for example vehicles who had nodata for the period, e.g. for fleets who have added new vehicles ordecommissioned vehicles periodically in their contract.

As shown in a graph 358 in a top portion of the user interface 355, afleet report for all vehicle groups 364 breaks down the average speedfor all vehicles in a fleet for that year 364 by each month (May 2010356-5, June 2010 356-6 . . . April, 2011 356-4). As shown, the monthsare along and x-axis whereas the speeds (from 0-10 mph) are along ay-axis. Each of the bars 356-5, 356-6 . . . 356-4 along the y-axis showaverage speed for each month. Bars 356 can be colored to conveyinformation, for example, bar showing the month with the highest averagespeed 356-9 of about 9 mph, is a different color (e.g. blue) than thebars for the other months (e.g. green).

At the bottom of the trend report 355, a fleet report 335 e similar tothe fleet reports 335 a, 335 b, 335 c, 3355 d in FIG. 3A shows rankedspeeds for the vehicles in the group 357 in the month with the highestaverage speed 356-9 in the graph 358 in a top portion of the userinterface 35. Each vehicle v1, v2 . . . vn is ranked from highest tolowest for that month, with bar graphs for miles per hour for eachvehicle shown along the x-axis and rank from highest to lowest in alongthe y-axis. The display could be configured to allow a user to selectany month for a breakdown.

The trend data can include operational performance against at least onecriterion, the at least one criterion including a criterion selectedfrom at least one of: a user-configurable criterion; a criterion derivedfrom GPS event data; a criterion derived from data other than GPS eventdata; a criterion derived from traffic data; and a criterion derivedfrom industry data. FIG. 3F shows at 390 another example of trend reportand alert based on a trend analysis. As shown, a “Stories” 390 reportshows that in a fleet of vehicles, 202 vehicles had more than 20 highspeed events in a given month. As shown, the alert 390 shows, based on acriterion derived from the GPS event data, which shows that the Trendingfor the operational metric is high 391. While such a criterion can bederived from GPS event data from the fleet from that user, it can alsobe derived from non-GPS event data such as industry standard dataderived from, for example GPS data of other users or external databasesthat hold data related to operational statistics.

FIGS. 3H and 3I show other examples of a detailed trend report 360 for afleet and employees from trending analysis as described above. Thedisplay shows a “head to head” analysis of two drivers v1, v2, each ofwhich can be selected by drop down menus 360 a, 360 b, which can also beconfigured to be searchable. The head to head analysis can be selectedusing a drop down and/or searchable menu 361 for over any over a timeperiod, for example 3 months, 6 months, a past year, a selectable year(e.g. 2009, 2010, 2011) or “all” (e.g. a full time period for which datawas collected for a given user). Again, it will be noted that the timeperiod available to a given user depends on how much GPS event datastored for each driver and/or vehicle. For example, a user whose fleetdata is collected starting Jan. 1, 2011 would not have options for databefore that time. Similarly, data would not be available for a givenvehicle or driver for any time period where data was not collected froma GPS device associated with that user or driver. Once the vehicles v1,v2 and the time period are selected, a user can, via an input 367, runthe comparison.

A top section 362 of the page shows a “versus” trend comparison, whichpresents graphics comparing each vehicles' v1 v2 performance underoperational metrics 302 as described herein, for example: Engine On/Off302 a, Vehicle Mileage 302 b, Vehicle Idling 302 c and Average Speed 302e. As shown in FIG. 3H, each operational metric 302 includes a bargraphic 365, where the left-side 365 v 1 of the bar corresponds to onedriver v1 and the right side 366 v 2 of the bar corresponds to anothervehicle v2. A visual indicia for the bar, for example a color, is givenfor each driver v1, v2, which allows a user to readily compareperformance trends and statistics under each operational metric 302 foreach driver v1, v2 for the time period selected (e.g., 2009). A textgraphic 366 v 1 may also give statistical trend data. For example, asshown in FIG. 3H, driver v1 has under “Engine-On Time” 302 a, a greencolor on the left-side 365 v 1 of the bar that is not as long as vehicle2's v2 red color on the right-hand side of the bar 365 v 2. Textgraphics 366 v 1, 366 v 2 at the left and right hand extremes of the barshow respectively that driver 1's v1 engine-on time is 5,234 minutes 366v 1, whereas driver 2's v2 engine on time is 7,556 minutes 366 v 2. Inthe example shown in FIG. 3I, driver v1 has under “Engine-Time” 302 a, agreen color on the left-side 365 v 1 of the bar that is again not aslong as vehicle 2's v2 red color on the right-hand side of the bar 365 v2. In FIG. 3I, text graphics 366 v 1, 366 v 2 at the left and right handextremes of the bar show respectively that driver 1's v1 engine on timefor all years is 280,312 minutes 366 v 1, whereas driver 2's v2 engineon time for all years is 298,498 minutes 366 v 2. The statistics aregiven in the same layout for Vehicle Mileage 302 b, Vehicle Idling 302 cand Average Speed 302 e, thus allowing a user to readily see and comparehow each driver v1,v2 performed for the time period selected (e.g. theyear of 2009, “all years”).

A bottom section 363 of the page shows an XY graph which plots thestatistics for each driver in increments for the “versus” trendcomparison. Page tabs 368 for the graph report 363 allows the user tosee XY graphs 363 for each of the operational metrics Engine On/Off 302a, Mileage 302 b, Vehicle Idling 302 c and Average Speed 302 e. As shownin FIG. 3H, Mileage 302 b for a year is presented, whereas in FIG. 3I,Engine-On Time 302 b for “all years” is presented. In FIG. 3H, along theX-axis are increments of months, and along the Y-axis is vehicle miragein 1000 mile increments. In FIG. 3I, along the X-axis are increments ofyears for “all years”, and along the Y-axis is Engine-On time in minutesper month. Each driver v1, v2, has a bar graph 364 v1, 364 v 2 plottedalong the XY axis showing their individual performance over time. Avisual indicia for the bar, for example a color, is given for eachdriver v1, v2, which allows a user to readily compare performance trendsand statistics for the operational metric 302 for each driver v1, v2 forthe time period selected, and can be configured to correspond to thecolors assigned to each driver in the top portion 362 of the report.

Also, one or more trend bar graphs can be added to show a comparison forat least one criterion, for example a criterion selected from: auser-configurable criterion; a criterion derived from GPS event data; acriterion derived from data other than GPS event data; a criterionderived from traffic data; a criterion derived from traffic data; and acriterion derived from industry data. For example as shown in FIGS. 3Hand 3I, a fleet average bar 364avg shows a fleet average performance forthe operational metric 302 selected (e.g., Vehicle Mileage in FIG. 3H,Engine-On Time in FIG. 3I). Accordingly, a user can readily see acomparison of the selected drivers v1, v2 against one another, but alsoas against the selected criterion or criteria. In another embodiment(not shown), the criterion can be drawn from industry data as describedherein, and the representation of the trend can be, for example, graphicpresentations such as a bar graph shown showing performance against anindustry benchmark derived from the industry data (e.g. industryaverages for operational metrics, best-of-class industry averages, goalsmet/unmet vs. industry standards). For example, a graph could show anaverage of the top percent of industry performers for which there isindustry data. The screen could also shown goal benchmarks set by auser, as could be developed from industry data, and whether the vehiclesor fleet are meeting those goals.

As shown in FIG. 3J and FIG. 3K, any number of vehicles or drivers v1,v2 . . . vn can be added to the graphics to permit comparisons asdescribed above. For example, FIG. 3J shows a multi-vehicle graphic 365where a user is presented with an XY axis 363 for the operational metricMileage 302 b for the year 2009, similar to those described above withrespect to FIGS. 3H-3I, which includes an input area 360 a for adding asmany vehicles v1, v2, v3 . . . vn as a user desires.

As shown in FIG. 3J, 3 vehicles/drivers v1, v2, v3 are compared for theyear 2009. In another embodiment, the system can be configured toanalyse GPS data other criteria data (e.g., industry data) to allow forintelligent reporting. For example, as shown in FIG. 3J, a text graphic369 also shows the totals for all vehicles selected, as well as a “PeakPeriod” which the month with the peak driving mileage (August 2009), aswell as the monthly mile total for the vehicle/driver with the highestmileage that month (v1 with 8711.62 miles in August 2009). Thus thesystem thus shows trend data along with, for the drivers selected, thedriver who was the largest cause. The system can be further configuredto analyze the GPS event history for at least one driver's performancefor at least one operational metric, identify a change in performance inat least one operational metric over a time period; provide, for thegraphic user interface, the representation of the trend, the trendincluding a trend showing the change in performance for the operationalmetric.

FIG. 3K shows a multi-vehicle “Top 5 Comparison” graphic 370 where auser is presented with an XY axis 363 similar to those of FIG. 3H to 3Jfor the operational metric “Idling” 302 c for the year 2009. The graphplots the minutes spent idling for the “top 5” vehicles v1, v2, v3, v4,v5 for the year 2009. As will be understood, the “top 5” may show eitherthe least amount of minutes spent idling, which is a positive performingstatistic, or the “top 5” could be configured to show those in the fleetwith the highest minutes spent idling, which would be a negativeperforming statistic. A text graphic 369 also again shows the totals forthe top 5 vehicles, as well as a “Peak Period” which the month with thepeak idling time (September 2009), as well as the idling minute totalfor the vehicle/driver with the highest idling minutes that month (v4with 11,349 mins. in September 2009). Thus the system thus shows trenddata along with, for the top 5 drivers, the driver who was the largestcause.

In another embodiment, system can be configured to proactively generatereports or alerts based on, inter alia, analyses of GPS event data andnon-GPS event data as described herein. The system can be configured toanalyze the GPS event history for at least one driver's performance forat least one operational metric, identify a change in performance in atleast one operational metric over a time period; provide, for thegraphic user interface, the representation of the trend, the trendincluding a trend showing the change in performance for the operationalmetric. For example, in a current time period where GPS vehicle data isshowing that an operational metric is trending above or below from aprior time period, the system can be configured to report and/or alertthe user. For instance, in a current month where idling is up X % overthe prior month, the system can be configured to deliver an alertshowing the total idling for the present month and thevehicle(s)/driver(s) with the highest idling minutes that month, therebypinpointing a cause. Similar alerts could be configured for anyoperational metric, (average speed, mileage, speeding, etc.) and for anytime period (day, week, month, quarter, year, etc.) Comparisons could berun on other bases as well, for example, a delta for an operationalmetric from another time period (e.g., idling is up or down X % from thesame month of the previous year, or the same week of the previous month,etc.) Such analyses can be performed for a single driver up to an entirefleet.

Criteria developed from GPS event data and non-GPS event data such asindustry data or historical GPS event data can be used to developcriteria to configure such benchmarks. For example, where historical GPSdata and/or industrial data show peak periods for certain operationalmetrics, a higher percentage threshold could be established beforesending an alert than in a non-peak period. The system could also beadapted to incorporate goal benchmarks, and to alert a user when adriver is or is not meeting or exceeding benchmarks.

In another embodiment, the system can be configured to develop criteriausing industry data from industry databases and/or historical GPS eventdata. For example, industrial and/or historical GPS data may show driveror fleet performance metrics and trends for given operational metrics.The system can be configured to facilitate a user in understanding anddeveloping internal goals as against benchmarks developed fromindustrial and/or historical GPS data. For instance, the system could beconfigured to alert the user that it should set up an idling report fora given driver/vehicle, or that a mileage report should be set up forthe fleet, based on the trending data from past performance.

In another example, the system could be configured to allow the user toset monthly fleet goals for a plurality of operational metrics. Insetting each goal, the system could send a facilitating message,alerting the user as to how the goal compared against a criterion suchas an industry benchmark from industrial data and/or a benchmark basedon historical GPS event data. For example, a user enters a goal for thefleet in a goal entry field (not shown) of keeping average minutes pervehicle for idling in a peak month to 5000 miles. The system can beconfigured to access historical GPS data and industry data to comparethat goal against industry benchmarks and send a facilitating message,such as: “Only X % of fleets keep average idling per vehicle under 5000miles.” Analysis of fleets and vehicles for that use can be filtered byany number of factors to target the goal-setting benchmarks, forexample, by geographical region or other relevant filtering data. (e.g.state, city, zip code, service area, comparable cities), fleet size,types of vehicles (truck, car, vehicle class), operational period (year,month), type of business (food delivery, furnishings delivery, packagedelivery), and so on. The system can further be configured to allow suchgoal settings for fleet subsets or selected drivers.

As will be understood, as more GPS data events are accumulated, accuracyand options for reporting can become more robust as well.

As explained above, any of the presentations above could be configuredsuch that criteria trend graphics can be added to show a comparison forat least one criterion as described herein (e.g.: a user-configurablecriterion; a criterion derived from GPS event data; a criterion derivedfrom data other than GPS event data; a criterion derived from trafficdata; a criterion derived from traffic data; and a criterion derivedfrom industry data).

In one embodiment, the computer system is configured to identify a trendfor at least one operational metric for a first period; provide acriterion for the operational metric; identify a trend for the at leastone operational metric for a second period; compare the trend for thefirst period against the second period to identify a change ofperformance for the trend; and determine if the change of performancefor the trend meets the criterion. For instance, a user could identify atrend of high idling (e.g. up 7%) for a given month, and set a criterionfor idling. For example, the user may input a benchmark of reducingidling by 5%. The system could then analyze GPS data to identify theidling trend for the following month, and determine if the fleet idlingis or is not meeting the 5% reduction. As will be understood, the datacan be provided over any selected time period(s), per driver/vehicle, aselect set of drivers, fleetwide, and for any operational metric, and soon.

FIG. 4A shows another example of an interface for a report for anemployee and vehicle, as could be accessed, for example, in a page fordispatching vehicles to job sites. As described above, commerciallyavailable trading application that allows fleet owner to manage anddirect fleet activity and performance like embodiments described isFleetMatics® FleetMatics GPS fleet tracking, which can be configured toaccept and process GPS data from commercially available GPS device fordispatch. In various embodiments, the system is programmed work inconjunction with a system configured to provide a location and can alsoprovide record of a route recorded by a GPS (Global Positioning System)device, for example, using an on-board unit which uses technology suchas GPS to monitor a vehicle's positions and transmit wireless uploads toa central host system, as described herein. As shown in FIG. 4A, a useris presented with an interface 400 for viewing and managing currentjobs, shown as a “Dispatch Tab (Job List)” 403. The interface 400includes a screen which displays a number of management tools, includingthe following features:

A “Dispatch|Jobs List” page title 401.

A “Choose Drivers” 402 (text link) provides an entry region that can beselected by an input device such as a mouse, which when selected it willopen a multi-select filter. The system is configured to load a list ofdrivers, which the user can select. The system can further be configuredsuch that if there are drivers selected when the filter is closed, thenlink will display as: “7 Drivers Selected (x)” with an input to clearthe list, e.g. a “clear/delete icon.”

In an embodiment higher level or more frequently used features can beincluded in a easily accessed or visualized area, such as a “QuickLinks” 404 region. As shown in the embodiment, the Quick Links 404includes selections for “Manage Customers 408,” “Create a New Job” 406,and “Upload Jobs” 410. As will be understood, other features could bemoved in or out of the easy access area, and further could allow suchfeatures to be moved either at the system administrator level or higher,or at a user level.

One option for presenting the list of jobs comprises a page 400 that canbe configured to allow a user to apply filter criteria for the jobdispatch. As shown in FIG. 4A, the system is configured to enable a userto access the job listing via a “Job List” 403 tab, which includes atable 420 that lists the jobs. The table includes rows 415 a, b . . . nfor each job, and columns listed under column headers 424 for Job ID426, Customer Name 427, Customer Address 428, Job Type 429, Status 430,Driver, 431 Scheduled time of arrival 432, Priority 433 and Actions 434,which are described in more detail herein.

The page 400 also includes a job list criteria selection region 412 forselecting the criteria for the jobs list display 420. A “Date” area 416loads results based on selected date. The system can be configured todefault to the current date, however the area 416 allows a user toselect a date range via selection entry areas 416 a, 416 b as describedbelow. The job list criteria selection region 412 also includes an inputentry “View” 418 configured to allow a user to load the selected jobslist once the criteria are selected.

A jobs dropdown 414 allows a user to select from a predetermined list ofoptions for the types of jobs the user desires to view. The dropdownfeatures the following options, as follows:

As shown in FIG. 4B a “Today's jobs” 414 a feature loads all active jobson the system and any closed, completed or cancelled jobs which statuschanged that day. In an embodiment this option can be a default, howeverother defaults or no default could be configured as well.

As shown in FIG. 4C, an “Active Jobs”414 b feature from the dropdown 414causes another field to load, shown as a selectable date field 416 a.The “[Active Jobs 414 b] up to [date field] 416 a (NB)” are active jobsloaded based on a scheduled time and include that days current jobs andany older jobs. Although the date field 416 a defaults to the currentday, the date field 416 a allows a user to select any day, whereupon thesystem is configured to load all active jobs until that selected day.The input entry “View” 418 allows a user to load the selected jobs listonce the criteria are selected.

As shown at FIG. 4D a “Completed Jobs” 414 c feature also loads seconddate field 416 b, shown as loading to the right of the first date field416 a: “Completed Jobs” 414 c from a date field 416 a up to “date field”416 b. FIG. 4D shows a “Cancelled Jobs,” 414 d feature which loads thefield: “Cancelled Jobs 414 d from “date field” 416 a up to “date field”416 b.” The input entry “View” 418 allows a user to load the selectedjobs list once the criteria are selected.

As noted above, FIG. 4A shows the system is configured to enable a userto access the job listing via the “Job List” 403 tab, which includes thetable 420 that lists the jobs. The table includes rows 415 a, b . . . nfor each job, and columns listed under column headers 424 for Job ID426, Customer Name 427, Customer Address 428, Job Type 429, Status 430,Driver 431, Scheduled time of arrival 432, Priority 433 and Actions 434,which are configured to act as filters for the job list 420. Alsoincluded is a “Check Box” 445 column where each job listing 422 a . . .n can be selected with a user input (e.g. mouse click, touch, orkeystroke) for the interface. In an embodiment where the job list isdisplayed as multiple pages, choosing a “Select All” check box canselect all jobs and not just the ones on the particular page displayedto a user.

The job list 420 can be ordered by column heading 424, which order ismaintained when a filter is applied for that column 424. The filters canbe configured to always be displayed. A filter region 444 includes anumber of filtering features which are configured to filter the columns424 of the job list table 420. As described above embodiments, filterscan include:

Job ID 426—text box input field 446

Customer 427—text box input field 447

Address 428—text box input field 448

Type 429—dropdown menu 449

Status 430—dropdown menu 450

Driver 431—dropdown menu 451

Scheduled Time 432—not searchable, and

Priority 433—not searchable.

For example, a dropdown “Job Type” menu 449, dropdown “Status” menu 450,and dropdown “Driver” 451 menu are each configured to allow a user tofilter the job list by job type 429 as described herein, status of job430, or driver for the job 431 respectively.

In an embodiment the Status 430 items can be configured to updatewithout a page refresh being required. The system can be configured toshow all types and statuses by default, or other default configurationscan be designed. In the “Status” 430 menu 450, exemplary statuses caninclude:

-   -   1. Open    -   2. Received    -   3. Accepted    -   4. En Route    -   5. In Progress    -   6. On Hold    -   7. Complete    -   8. Closed    -   9. Cancelled    -   10. Return To Dispatch    -   11. Deleted (the system can be configured not to show deleted        jobs display on the jobs list page).

The “Customer” name column 427 includes an input field 447 for allowingthe ordering of the customer names. Similarly the Job ID 426, Address428 and Job Type 429 columns have respective fields 446, 448, 449 forordering the job list 400 accordingly.

A “Scheduled” 432 column shows the scheduled arrival times for each ofthe jobs 422 a . . . n. A “Priority” 433 column gives an indication ofpriority of the job, for example using an alerting icon (e.g., anexclamation point, a colored icon, or any other graphic conveying apriority).

An “Actions” 434 item is configured to allow a user to take a number ofactions for the job and job dispatch. A user can select an “Action”button 422 a . . . n which loads a number of other options. Exemplaryaction items can include:

-   -   Find Nearest Vehicle—(loads a “find nearest” pop-up described        below with respect to FIG. 5):    -   Re-assign    -   Recall    -   Complete    -   Cancel.

If job is identified as complete, further action options are “Closed”and “Re-open.” If job is closed, the system is configured to present a“Reopen” option; in an embodiment “Reopen” is the only option for aclosed job. If the job is open, but there is no driver assigned, furtheroptions can include: “Assign,” “Complete,” and “Cancel.”

System configurations for an embodiment for when the “Action” isselected are described below. While the description is provided in termsof selecting and clicking on a buttons via a GUI input device such as amouse, as will be understood, both here and throughout this disclosure,interfaces can be configured to operate with any input method as knownin the art, including touch screens, keystrokes, and so on. The systemis configured to allow a user to select the following actions:

-   -   Assign—clicking this will assign the selected driver and return        to main screen. If the current driver remains unchanged and the        button is clicked, it will act the same as the cancel button—if        a user selects this the main screen will grey out and a “Choose        Driver” pop-up will load which lists all drivers for the fleet.        Clicking a “cancel” button will close the pop-up and return to        the main screen 400, having saved no changes. Clicking an        “Assign” button assigns a driver selected from the driver list        and return to main screen 400. If no driver is selected and the        button is clicked, it will act the same as the “cancel” button.        A user thus must choose a driver, click “cancel,” or be        cancelled by default; the system is configured such that a user        cannot choose “no driver.”    -   Reassign—if user a selects this, the main screen 400 will grey        out and a “Choose Driver” pop-up loads, which lists all drivers        for the fleet. Clicking on a “Cancel” button closes the pop-up        and return to the main screen, having saved no changes, leaving        the current driver unchanged. Selecting an “Assign” option,        assigns a driver selected from the driver list and return to        main screen 400. If no driver is selected and the button is        clicked, it will act the same as the “cancel” button. A user        thus must choose a driver or click cancel or be cancelled by        default; the system is configured such that a user cannot choose        “no driver.”    -   Choose Driver—a “choose driver” can be configured as a dropdown        menu that lists all drivers for a fleet, which the user can        select.    -   Cancel—clicking this button will close the pop-up and return to        the main screen 400, having saved no changes. The system is        configured such that if a user selects this they will be shown a        pop-up asking “Are you sure you want to cancel this job?”        message and will have to select “Yes” or “No.” A “Don't show me        this message again” checkbox in the pop-up can also be included.    -   Close—The system is configured such that of a user selects this        he or she will be shown a pop-up asking “Are you sure you want        to close this job?” message and will have to select “Yes” or        “No.”    -   Recall—if the user selects this they will be shown a pop-up        asking “Are you sure you want to recall this job?” message and        will have to select “Yes” or “No.” A “Don't show me this message        again” checkbox in the pop-up can also be included.    -   Complete—if user selects this the main screen will grey out and        a pop-up will load including an editable text “Price,” which        populates with whatever entry a driver has entered. A “Driver        Note” editable text field can also be provided which populates        with whatever text the driver has entered.    -   Reopen—The system is configured such that of a user selects a        closed job on the main page and clicks “Reopen,” the job status        is updated as reopened. In the embodiment no pop-up is        associated with this function.

In an embodiment, the system is configured to allow a user to selectjobs, for example via a selection input area, shown as checkboxes 445 a. . . n, where the system can then display the number of jobs selected:“N jobs selected.” The system can also be configured with an “Export”action button 456, which becomes active when one or more checkboxes havebeen checked. Clicking the export button 456 will load two options:

Excel—opens a CSV file in excel displaying the selected jobs, and

PDF—opens the selected jobs as a PDF for printing.

As shown in FIG. 4F, a user is presented with an interface 460 forviewing and managing jobs, shown as a “Schedule View” 463. The pageincludes the following fields and interface inputs, as follows:

-   -   Create New Job 461—This button will load a pop-up.    -   Manage Customers 462—Shortcut to a “manage customers” screen, an        embodiment of which is described herein with respect to FIG. 10.    -   Upload Jobs 464—Shortcut to an upload jobs section configured to        allow a user to upload jobs.    -   Choose Drivers 466—Enters full or partial name and click the        search icon.    -   Date 468—Configured to allow a user to select the date the user        wishes to view (defaults to current date).

In the embodiment shown in FIG. 4F, the system is configured to presentthe job listings via a “Schedule View” 463 tab, which includes tables470, 480 that lists unassigned jobs 470 and drivers 480 along respectivetimeline grids are described below.

The “Unassigned Jobs” 470 region lists all jobs 472 a . . . n that havenot been assigned to a driver along a grid. The table includes rows 472a, b . . . n for each job, and columns showing where the jobs arescheduled along a scrollable horizontal time axis 474, shown in halfhour increments. The time axis 474 which shows blocked off scheduledtimes 476 a . . . n for each job. The system is configured such thatclicking on one of the jobs 476 a . . . n in the timeline 474 grid willdisplay 478 the name, address, job type and estimated duration.

In an embodiment, the system is configured allow a user select the jobto perform actions, for example by right-clicking on a job to performthe following functions using, for example, embodiments as describedherein:

1. Assign the job to a driver.

2. Find nearest drivers.

3. Update status.

The “Drivers” 470 region lists all drivers 482 a . . . n that areassigned jobs along a time grid. Another scrollable time axis 484 isconfigured to show blocked off scheduled time 486 a . . . n for eachdriver. Clicking on one of the jobs in the timeline 484 grid willdisplay the name, address, job type and estimated duration (not shown).

In another embodiment, the system is configured allow a user toright-click on a job to performing the following functions using, forexample, embodiments as described herein:

1. Reassign the job to a different driver.

2. Find nearest drivers.

3. Update status.

As shown in FIG. 5, a user is presented with a “Find Nearest” interface500, shown as a map page 500. As noted above, embodiments of the systemare programmed work in conjunction with a system configured to provide alocation and can also provide record of a route recorded by a GPS(Global Positioning System) device, for example, using an on-board unitwhich uses technology such as GPS to monitor a vehicle's positions andtransmit wireless uploads to a central host system, as described herein.The system can also be configured to integrate with mapping systems orsoftware which can and configured to display the location of eachvehicle as well as calculate and project a route as a map 512, 514.

If a “Find Nearest” button is clicked from a work order or an actionbutton 422 a . . . n (see FIG. 4A) as described above, in addition tostandard features, the following items are displayed:

A “Criteria” region 502 is configured to display filtering criteria. Inan embodiment the criteria include a time criterion “Date/Time” 504. Thedate and time criteria can be configured to default to the current dateand time, but can configured to allow a user to change the date and daterange, including historically. The criteria also can include a groupfilter 506 to allow the vehicles to be filtered by group. Selecting a“Run” button 508 generates the results for the selected criterion forthe page 500, shown in the embodiment as a vehicle list 509 and a mapregion 512.

An information bar 516 is configured to display:

Job ID 518

Customer Name 520

Address with a “Point of Interest” or “POI” for the user, if applicable)522 and Status dropdown 524.

A vehicle list 509 displays the nearest 5 vehicles 510 a . . . 510 e,however the system can be configured to show any number of vehicles. Ifthe vehicles have an associated driver a driver name will appear. If adriver has a working version of a driver application for integratingwith the system (not shown), a phone icon 511 will be visible. Once avehicle with associated driver and working driver app is selected thenthe “Assign” button 524 will become active at the bottom. The user canclose the page by selecting a close button 526.

For example in one embodiment, an on-board GPS unit uploads one or morelocations of a vehicle a central host system. The location is presentedto the user on the page 500, for example, as map layout 512. The mappingsoftware calculates a route 532 from the vehicle's location 528 to a joblocation 530, which is displayed in the interactive graphic 512.Electronically presented maps are available over the Internet. See, forexample, Google Maps (http://maps.google.com/maps), Microsoft Bing Maps,www.mapquest.com, www.mapsonus.com, www.maps.expedia.com,www.maps.yahoo.com (accessed through www.yahoo.com), www.maps.com,www.maps.excite.com, (accessed through www.excite.com), andwww.mapblast.com. Also see U.S. Pat. Nos. 4,974,170, 5,682,525 and6,148,260, and U.S. patent application Ser. No. 13/082,222 the entiretyof each of which is incorporated by reference herein.

FIG. 6 shows an example of an interface 600 for viewing and managingcurrent jobs, shown as a “Manage Job Types” 602 page. The interface isconfigured to allow users to create new and manage existing job types.In the embodiment the page is configured to be in an administrativesection.

The page 600 is configured to such that a user can establish newcategories and parameters jobs to be dispatched. Once a job type iscreated, jobs can be categorized by type. A “Create New Job Type”603region includes the following entry fields or selectable parameters forcreating the job type:

-   -   Name 605: the user enters the name of the new job type (e.g.,        Install, Site Visit, De-install, Replacement, Training,        Delivery, etc).    -   List Price 606: the list price for the job type.    -   Est. Duration 607: the estimated duration to perform the job        (e.g., in minutes).    -   Short Code 608—a code for the categorizing of the job. In one        embodiment the code is a mandatory feature, although in need not        be.    -   Price Editable by Dispatch 609—(checkbox): allows a dispatcher        to edit the list price.    -   Price Editable by Driver 610—(checkbox): allows the driver to        edit the list price.    -   Signature required 611—(checkbox): the dispatch or work order of        the job requires a signature by a customer.    -   Include Driving Time in Duration 612—(checkbox)—includes driving        time to dispatch location in overall job duration    -   Save button 614

A “Job Types” 615 section lists the job types for a fleet in a tabularformat. A filter field 616 is configured to allow a user to type textinto the text field and click a “Go” 617 button to execute a filteringfunction which filters a job types list 615; the job types list section615 shows the filtered results accordingly. Once the filter has beenrun, the system can be configured to load a button or other input entryobject that a user activates (e.g., via mouse click) to clear the list.

In one embodiment the columns are arranged by job type parameters suchas those described above, including:

-   -   Name 618    -   Short Code (not shown)    -   List Price 619    -   Est. Duration 620    -   Number of Total Jobs 621—total number of jobs for the job type,        if any.    -   Edit by Dispatch 622—displays as an inactive check box (unless        in edit mode)    -   Edit by Driver 623—displays as an inactive check box (unless in        edit mode) Signature Required 624—displays as an inactive check        box (unless in edit mode)    -   Enabled 626—displays as an inactive check box (unless in edit        mode)—please note: jobs are automatically enabled when created    -   Include Driving Time in Duration 625—displays as an inactive        check box (unless in edit mode)        The system can also be configured top show an “Edit” object 627,        shown as an icon, which when clicked or otherwise activated the        text and check boxes in the appropriate row will become active        and can be edited. The system can further be provided with a        “Delete” 628 input, which when clicked or otherwise activated        this will remove job. In an embodiment, a delete function is        only available if the job type has no active jobs, in which case        the system can be configured not to show the Delete if there are        active jobs.

FIG. 7 is an example of an interface 700 for creating jobs for a fleetcustomer, shown as a “Create Job” 702 page. The interface 700 isconfigured to allow users come to create new jobs for existing or newfleet customers. In an embodiment, the page 702 can be configured topresent regions to be completed in sequence, although as will beappreciated other configurations are possible as well.

In an embodiment, the interface 700 is configured to present a customerinformation region 703 which includes areas for creating a new customer704 or searching for an existing customer 707. A “Search ExistingCustomer” area 708 includes an input area or dropdown menu that isconfigured to allow a user to input a customer ID or customer name,which can be searched by clicking a “search” button 709. In anembodiment, a user can start typing in the search field 708 to loadsearch results. The system if configured to load a list of customernames, for example with full names, and having the typed characters willbe highlighted. The list is configured to search both customer names andan external ID starting with text. A “Create New Customer” area 704includes a field 705 for inputting a new customer's name, which can beentered into the system via an input entry object 706 which a useractivates (e.g., by clicking a button 706). The user can click thisbutton 706 to generate a new customer, as described below.

Next, a “Customer Location” 710 region is configured so users can selecta location from a selection input 711 based on the customer informationfrom the customer information region 704. In an embodiment the customerlocation selection input 711 is a dropdown menu configured to default tothe customer's headquarters or a default address associated with thecustomer. Alternatively, the system is configured to such that a usercan input a new location, shown as a “New Location” button 712 a usercan click to generate a new location. This loads a view/edit locationpop-up with the customer name and external ID in place (see FIG. 8).

In an embodiment the “Customer Location” region 710 is also configuredto include fields for further customer information including: ContactName 713, Contact Phone Number 714, and an External ID 715 (configuredto be associated with a location). A Notes area 716, can also beconfigured to show a partial amount of the notes, followed by a link atthe end that says “More”, which links to more detailed (e.g., whenclicked, a speech bubble will load displaying the full note. A map 717shows the selected location).

Next, a Job Details region 718 is configured so users can enter jobdetails. As with the other regions, in an embodiment the Job Detailsregions includes user entry fields, including text fields and dropdownmenus, comprising fields as follows:

-   -   Job Type 719—users can select one of the predefined job types.    -   Job Description 720.    -   List Price —721, which can be configured to load based on the        job type 719 selected, and can also be configured to be edited        thereafter. In an embodiment, If left blank the field defaults        to 0.00. In an embodiment a default user currency can also be        provided, which can be configured as a select list so users can        change if required.    -   Estimated Duration 722—configured to be in minutes; but can be        configured to show other time increments as well. The system can        be configured to require the time increment be greater than        zero.    -   Scheduled Start Date 723/Time 724    -   Time Zone 725—configured as a dropdown that defaults to a user's        time zone, but can be configured to be changed.    -   Drivers 726—configured to have a user select from a dropdown,        but can be configured as a text entry or search field.    -   Link for Find Nearest Drivers 727    -   Save 729—clicking this will save the job, close the window and        display the job in the jobs list    -   Discard 728—clicking this will close the widow without saving        the job.        In an embodiment all fields except “List Price” and “Find        Nearest” can be configured to be mandatory, although as will be        appreciated the system need not be configured thus, and that any        fields can be made optional or mandatory depending on design or        business needs.

As noted above, in an embodiment, the Link for Find Nearest Drivers 727can also be provided. For example, the system can be configured with anoption to show drivers who are available for dispatch, which can beenabled by default. An exemplary “Find Nearest” interface is describedwith respect to FIG. 5. The system can further be configured tocommunicate with drivers' devices that in turn signal to the system thatthe drivers are available for dispatch. For example, a driver can beprovided with a portable device or application therefor, such as a PDA,smart phone, or GPS device for a vehicle, which includes functionalityfor signaling to the system, for example by a driver input or a vehiclestate, that the driver is available for dispatch. The system then can beconfigured to show these drivers when the Find Nearest Drivers 727 linkis selected.

In another embodiment the system can be configured to automaticallypopulate with the 5 nearest drivers. The system can be configured to letusers filter the driver list by groups (drivers attached to vehicles ingroups. They can select one of the five vehicles and the map will updateto show that vehicle in relation to the location (as for example, shownin FIG. 5 as described herein, where a user is presented with a “FindNearest” interface). The nearest drivers list will include their currentlocation and their estimated time from the customer location.

As shown in FIG. 8A, a user is presented with an interface 800 to createa job for a new customer. In an embodiment the interface 800 isaccessible via an “Create Job|New Customer” 802 page. A customerinformation region 801 is shown as information bar 801 is configured todisplay:

Customer Name 804

Customer Number 806

each of which can be configured to allow user to enter or search for anew customer.

In an embodiment the new customer interface 800 comprises user entryfields for entering data about the new customer, including text fieldsand dropdown menus, comprising fields as follows:

-   -   Search for Address/POI 808    -   Address Results 810 (from search)    -   POI Type 812 (dropdown)    -   POI Name 814 (Address)    -   Address—loads based on selection and is not editable.    -   Contact Name 816    -   Contact Number 818    -   Location 820 ID—a location external ID    -   Location Notes 822    -   Show on map 826 (checkbox)    -   Show addresses 828 (checkbox)    -   Map 824—displays location based on search criteria selected.    -   [Save & Continue] 830—clicking this button will save the        customer and the pop-up will refresh and load the previous        create new job screen with the customer details.    -   [Cancel] 832—clicking this button will reload create new job        screen without saving the customer details.

As noted above, in an embodiment, the system is programmed work inconjunction with a system configured to provide a location and can alsoprovide record of a route recorded by a GPS (Global Positioning System)device, for example, using an on-board unit which uses technology suchas GPS to monitor a vehicle's positions and transmit wireless uploads toa central host system, as described herein. The system can also beconfigured to integrate with mapping systems or software which can andconfigured to display the location of each vehicle as well as calculateand project route as a map 824.

For example, in one embodiment a user add jobs from a “Live Fleet” 324(FIG. 3) page with GPS data and mapping software which tracks vehiclesv1, v2 . . . vn. The page 324 can allow a user such as a dispatcher to,for example, locate and dispatch the closest vehicle to any job site andreroute the nearest vehicle as described herein. The page includes a mappage similar to that of FIG. 8A, including a map 824 and a customerinformation area 801. The map can also includes objects for a “point ofinterest” or “POI” 838, 839. POIs are locations and addresses identifiedor saved by a user for easy reference. The page may also include“hotspots” or frequent stop locations identified by automated systemsand methods, as described in U.S. patent application Ser. No. 13/458,088entitled SYSTEM AND METHOD FOR AUTOMATED IDENTIFICATION OF FREQUENT STOPLOCATIONS FOR VEHICLE FLEETS the entirety of which is incorporated byreference herein. Vehicle locations 840 (i.e., as tracked by GPS andpresented on the map 824) can also be presented.

For example in one embodiment, an on-board GPS unit uploads one or morelocations of a vehicle a central host system. The location is presentedto the user on the display device, for example, as map layout 824.Electronically presented maps are available over the Internet. See, forexample, Google Maps (http://maps.google.com/maps), Microsoft Bing Maps,www.mapquest.com, www.mapsonus.com, www.maps.expedia.com,www.maps.yahoo.com (accessed through www.yahoo.com), www.maps.com,www.maps.excite.com, (accessed through www.excite.com), andwww.mapblast.com. Also see U.S. Pat. Nos. 4,974,170, 5,682,525 and6,148,260, and U.S. patent application Ser. No. 13/082,222 the entiretyof each of which is incorporated by reference herein.

Once the customer information is inputted, the user can add a job in anumber of ways from various locations in the system interface, such asfor example a Live Fleet page (see, e.g.: FIG. 3, “Live Fleet,” 332). Inone embodiment the system is configured to allow a user to enter a jobfor a customer depending on, among other things, the information thesystem has about the customer. For example, referring to the systeminterface 800 can be configured such that a user can:

1. Right-click on a POI 838 that is mapped to a customer

2. Right-click on a POI 839 that is not mapped to a customer

3. Right-click anywhere else on the map 824 (including vehicles 840,etc.) These are described below.

If a user right-clicks on POI 838 that is mapped to a customer, thesystem is configured open a “create job” page (see as shown at FIG. 7)with customer and location populated. If a user to right-clicks on a POI839 that is not mapped to a customer, or where a user right-clicksanywhere else on the map, doing so opens an “add location page,” similarto that shown in FIG. 8A. As shown in FIG. 8B, the interface 800 isconfigured such that the user can search for customer in the customerfield 804 by typing. This will give a select list of results beneath835. The user can either choose an option from the list or use textentered to create a new customer 836, as described above. If a userchooses a customer the dropdown, the system is configured to populatethe external ID field 806 of FIG. 8A. As will be appreciated, other pageconfigurations could implemented or features added to assist the user.For example, for the POI 839 not being mapped to a Customer, text at thetop that reads, “First, let's create a Customer for this Job . . . ”could be added. Or a textbox could be configured to search for bothCustomer Name and Number (External ID) 806.

As shown in FIGS. 9A-9B, a user is presented with an interface 900 toedit a job. For example, the system could be configured to display an“Edit job” interface 900, for example as a pop-up that displays when auser clicks on other otherwise accesses an editing function for a joblisting.

The edit job screen 900 comprises an information region that includesbasic information about a job, and basic interface objects as follows:

-   -   “Edit Job” page title 902—page title    -   Job ID 904—text    -   Customer Name 906—text    -   Location Name and Address 908—text    -   Current Status 910—dropdown menu stating the jobs current        status, which can be changed by the user    -   [Save] 912—saves changes and returns to previous page when        clicked.    -   [Cancel] 914—closes window and returns to previous page when        clicked.

The edit job screen 900 also comprises a details tab 915, shown in FIG.9A, that includes user entry fields for editing data about a job,including text fields and dropdown menus, comprising fields as follows:

Job Type 916—dropdown (only editable when job is open and returned todispatch)

Description 917—text box

List Price 918—text box (only editable when job is open and returned todispatch)

Estimated Duration 919—text box

Scheduled Date 920—calendar selection

Estimated Start Time 921—text box

Time Zone 922—dropdown

The edit job screen 900 also comprises a location tab 930, shown in FIG.9B, that includes user entry fields for editing data about a job,including text fields and dropdown menus, comprising fields as follows:

Location 932—dropdown

Details 934—text (not editable), this includes all notes pertaining tothe location.

Map 936

The edit job screen 900 also comprises a Status History tab 938, whichcan include a status log or other historical information about thestatus of the job (not shown).

As shown if FIG. 10, in an embodiment a user is presented with aninterface 1000 for managing customers, shown as a “Manage Customers”page 1000. As shown in the figure, the page can be accessed via a “QuickLinks” 404 region as described herein (see FIG. 4A, 404, 408). The QuickLinks can also include “Create Customer” 1004 and “Create Job” 1006links, which link to user interfaces that provide these functions, forexample as described herein.

The page 1000 also comprises a Customer List 1012 configured to allow auser to view and edit customers of a fleet, which includes the followingcolumns:

Customer Name 1014 a . . . n

External ID 1016 a . . . n

Head Office Address 1018 a . . . n

Edit 1020 a . . . n—clicking this link will load an “edit customer”screen.

The interface page 1000 also includes a Filter 1008—configured to allowusers to filter the customer list 1012 by typing all or partial customername and clicking a “Go” object 1010. As with the other filters, a clearor “[x]” object 0109 can be provided to remove results.

In embodiment, the system is configured to include one or more TimecardReports for driver working time and payroll. Timecard Reports can beconfigured to record a driver's work status based on vehicle activity ordriver status input. The Timecard Reports can be made available as amanual or an automated/scheduled report. The system can be configured tointegrate the Timecard Reports with accounting systems and programsknown in the art, for example such as the commercial products andsystems for QuickBooks® and ADP®.

Drivers can be provided with an application which can be implemented tocommunicate with the system. In an embodiment, drivers can also beprovided with a Timecard Application configured to allow a driver toinput and record a driver's work status, such as Punch In/Out, breaks,and lunches. That status information will be sent to the system for usein Timecard reports as described herein. In an embodiment, if a vehiclefleet user or account is not using the Timecard Application feature, thesystem can be configured to provide reports based on vehicle activityusing operational metrics based on GPS events. The system can beconfigured to allow a user to choose the operational metrics used todetermine working hours reported, for example the operational metricsfor a start and end of the day. For instance, a start of day can bedetermined by operational metrics such as “first movement,” or “arrivalat first stop,” and so on.

As shown in FIG. 11A, in an embodiment, a Timecard Report includes a“Daily Timecard Report” is configured to show detailed stop information,and includes a reporting area for a driver to input information about astop, for example the reason for a stop (e.g., to justify stops whenthere is an exception).

As shown in FIG. 11B, in an embodiment a Timecard Report includes a“Weekly Timesheet Report” configured to show the amount of hours workedsummed for each day with overtime information.

As shown in FIG. 11C, in an embodiment a Timecard Report includes a“Payroll Comparison Report” configured to show a summary of hours workedby day.

As shown in FIG. 11D, in an embodiment driver status information can beincluded in a Timecard Report comprising an “Excess Payroll Report.”

In other embodiments, reports can include driver status information canbe included in various Reports and interfaces (e.g., via the Dashboardand Trending) as well as provided for Alerts.

The system can be configured to show Timecard Reports based on hoursworked and other vehicle and/or driver data. In each of the reports thatfollow, the system comprises configuration options that includeparameters for determining a work schedule. The reports and systemconfigurations for running reports are described below with the samereference numbers referring to the same or similar interface features.However, as will be appreciated, a particular report can be configuredwith or without various features or to comprise additional features.

in an embodiment, each report interface includes a selection region (notshown) for Vehicle/Driver Selection, which is configured to allow a userto select and run the based on drivers or vehicles. In one embodimentthe selection region can include a dropdown menu allowing a user toselect either “Vehicles” or “Drivers.” In another embodiment, theselection region can be configured as textbox, whereby the system can beconfigured to search vehicles or drivers for that user (e.g. a fleetaccount). In another embodiment, radio buttons can be configured toallowing a user to select either Vehicles or Drivers. As will beappreciated, other inputs for selection can be implemented. Where a userselects Drivers, a list of drivers is presented to allow the user toselect one or more drivers. Similarly, when a user selects “vehicles” alist of vehicles is selected. In embodiments, the system can beconfigured to default to either vehicles or drivers until the other isselected by a user.

In an embodiment, the system is configured to allow a user to run areport for a time period, for example a work week, a month, or one ormore days, using a date range selection field, such as at lest one“Date/Time Selection” 1102 selection field.

In an embodiment, the “Date/Time Selection” 1102 does not allow for atime of day selection, and the report is run only for entire days. In anembodiment, in addition to a date range and days of the week selection,the system is configured to allow a user to set a start and end pointsfor the time range such that the report can be run to include partialdays, as for example for shifts and “3rd shift” scenarios. The systemcan be configured to indicate the report only shows work activitybetween selected times, (e.g.: “Report Start” 1104 and “Report End”1106). In an embodiment, the system is configured to run the report tocapture 3d shift scenarios. For example, if the user enters an earliertime for the end of a shift “Report End” 1106) than for shift start(“Report Start” 1104), the system is configured to run the report with“Report End” 1106 run on the day after “Report Start” 1104.

As noted above, a user can select a Report based on operational metricsderived from vehicle activity. In an embodiment, the system isconfigured such that, if a user selects to run the report for driversand a system shows the user's fleet account is enabled with the TimecardApplication Feature, the user is given options to use either “StatusEvents'” or “Vehicle Activity” (not shown). In an embodiment “StatusEvents” can be provided as a default option. If the fleet account doesnot have the Timecard Application Feature enabled, or is running thereport for Vehicles, then the system is configured to present “VehicleActivity” and define Start and End events.

The system is configured to allow a user to define parameters for startand end day triggers. Options to define start of day triggers includethe following operational metrics including those derived from GPS eventdata:

-   -   Ignition ON    -   First Movement    -   Arrival at First Stop    -   Arrival at First Work Order    -   Arrival at one or more locations or areas. For example, the        system can be configured to allow a user to select multiple POIs        or predefined geographical areas for a start of day for vehicles        within the fleet. If a vehicle arrives at any of these        locations, the Start of Day is triggered.    -   Departure from one or more locations or areas. For example, the        system can be configured to allow a user to select multiple POIs        or predefined geographical areas for a start of day for vehicles        within the fleet. If a vehicle departs from any of these        locations, the Start of Day is triggered.

Options to define end of day include the following operational metrics:

-   -   Ignition OFF    -   Last Movement    -   Departure from Last Stop    -   Departure from Last Work Order    -   Last arrival at one or more locations or areas. For example, the        system can be configured to allow a user to select multiple POIs        or predefined geographical areas for an end of day for vehicles        within the fleet. If the last arrival for a vehicle is any of        these locations, the End of Day is triggered.    -   Last Departure from one or more locations or areas. For example,        the system can be configured to allow a user to select multiple        POIs or predefined geographical areas for an end of day for        vehicles within the fleet. If the last departure for a vehicle        is any of these locations, the End of Day is triggered.

In an embodiment, an option to “Ignore daily start or end travel whenless than X miles,” can be included so as to exclude undesired vehicleactivity from the report. The system can be configured to allow a userto select the mileage for example, using a dropdown menu for 0 miles, 1mile, 5 miles, and 10 miles (not shown).

In an embodiment, the system is configured to provide option to enterthe number of hours that the driver is to be paid each day. The systemcan be configured to calculate the amount of overtime for a driver usingthis value along with options for “Additional Paid Time” and “UnpaidBreak Time.” For overtime, the system can be configured to either havethe hours worked by day, or in another embodiment, the system isconfigured to have hours worked by a multiple of 7 days. The system isalso configured such that if the user is running the report usingvehicle activity, a user is presented with a number of additionaloptions to calculate hours worked, including an option to add an amountof “Additional Paid Time” to be added to the Hours Worked value and anoption to add an amount of “Unpaid Break Time” to be deducted from theHours Worked value.

In embodiments, for example embodiments including the Daily TimecardReport and Weekly Timesheet Report described herein, the system can alsobe configured with a “Print Option.” The Print Option includes a PrintOutput configured such that for multiple days and/or drivers, the systemis configured such that the report prints with a page break between theshifts/days and each driver. The system is also configured to allow aprint option for a landscape mode, which is used when printing to ensurethat the entire report is visible, and further prints with a “Notes”column. The “Notes” column can show in the printout, and is configuredto allow a driver to give an explanation for each stop. At the bottom ofeach driver's shift/day, the report can include an area for the driver'ssignature.

In an embodiment, the system interface can be configured to include an“Additional Option for Automated/Schedule Report” or “Automated Output”which is configured to send the report directly to each driver. Thedrivers selected for the Automated/Schedule report would get just thatdriver's report, whereas other recipients would get a report for alldrivers for the Report. The Automated Output is configured with theelements that the “Print Option” has.

In one embodiment, the Timecard Report includes a Daily Timecard Reportas shown at FIG. 11A, the output of which is presented as follows. Incertain embodiments the report is grouped by vehicle 1105, shown forexample a “John Smith—Vehicle 47.” The report then shows the stops forthe vehicle. The interface includes a Report Header area, which displays

Total Hours Worked 1108

Total Overtime 1110

Total Travel Duration 1112

Total Stop Duration 1114

The system interface also includes a Stops/Hours report area 1115 wherestops are presented in rows 1116 a . . . n. The system interface also inincludes columns for the stop rows, which include:

-   -   Arrival Time 1118    -   Location (both Address and “POI” or other geographic identifier        (e.g.: a “Geofence”) 1120    -   Travel Duration 1122    -   Distance Traveled 1124    -   Stop Duration 1126    -   A Notes area (e.g., for allowing the driver to justify stops)        1128.

If the system's user account in enabled with the Timecard ApplicationFeature, and the driver has logged status events that fall within thetime periods of the report, then the report can be configured withfurther rows for the logged status events be included amongst the stopswherever they fall chronologically.

The Timecard Report also includes a signatures area, shown in a footerarea 1129, which includes a signature line 1130 for the driver and asignature line for manager 1131.

in one embodiment, the Timecard Report includes a Weekly TimesheetReport as shown at FIG. 11B, the output of which is presented asfollows. In certain embodiments the report is grouped by date or day1132, for a vehicle 1105. The report included individual days 1132 a . .. n.

The interface includes a Report Header area, which displays

Report Start 1104

Report End 1106

Total Hours Worked 1108

Total Overtime 1110

Avg Start Time 1134

Avg End Time1136.

The system interface also includes a Stops/Hours report area 1115 whereworkdays presented in rows 1116 a . . . n. The system interface also inincludes columns for the workday rows, which include:

Day/Date 1138

Start Time 1140

End Time 1142

Hours Worked 1144

Break Duration if showing Status Events) 1146

Personal Duration if showing Status Events) (not shown)

Stop Duration 1126

Overtime 1148.

The Weekly Timesheet Report also includes a signatures area, shown in afooter area 1129, which includes a signature line 1130 for the driverand a signature line for manager 1131.

In one embodiment, the Timecard Report includes a Payroll ComparisonReport as shown at FIG. 11C, the output of which is presented asfollows. The interface includes a Report Header area, which displays

Report Start 1104

Report End 1106

Total Hours Worked 1108

Total Overtime 1110

Avg Start Time 1134

Avg End Time 1136.

The system interface also includes a Stops/Hours report area 1115 wheredrivers or vehicles are presented in rows 1150 a . . . n. The systeminterface also in includes columns for the workday rows, which include:

-   -   Drivers or Vehicles 1150 a . . . n, whichever was selected on        the report configuration    -   A Column for each day of the week 1152 a . . . g with the number        of Hours Worked in each cell. For the days of the week that were        not selected or do not have activity, cells can be filled with a        “-”.    -   Total Hours Worked 1154 summing the hours worked for the week.    -   Total Overtime 1154 showing the amount of overtime for each        driver. The Payroll Comparison Report also includes a footer        area 1156, which includes:    -   Total Hours Worked 1162 a . . . g for each day of the week    -   Grand Total 1164    -   Total Overtime 1168.

In one embodiment, the Timecard Report includes a Excess PayrollException Report as shown a FIG. 11D for a vehicle or driver 1105, theoutput of which is presented as follows. In certain embodiments thereport is grouped by date or day 1132, for a vehicle 1105. The reportincluded individual days 1132 a . . . n.

The interface includes a Report Header area, which displays:

Report Start 1104

Report End 1106

Vehicles with Overtime 1107

Total Overtime 1110

Avg Start Time 1134

Avg End Time 1136.

The system interface also includes a Stops/Hours report area 1115 whereworkdays presented in rows 1116 a . . . n. The system interface also inincludes columns for the workday rows, which include:

Day/Date 1138

Start Time 1140

End Time 1142

Hours Worked 1144

Break Duration (if showing Status Events) 1146

Personal Duration (if showing Status Events) (not shown)

Stop Duration 1126

Overtime 1148.

The Weekly Timesheet Report also includes a signatures area, shown in afooter area 1129, which includes a signature line 1130 for the driverand a signature line for manager 1131.

In an embodiment, the system is configured to allow a user to setparameters for logging hours worked by drivers for a fleet. Anadministrative section of an interface (not shown) can be configuredsuch that a user can assign a driver to a vehicle, as well as add, edit,or delete drivers. The system can also be configured to allow a user toadd contact information for the driver, such as an e-mail address or aphone number. The system can also be configured to track one or morevehicles for the fleet, including keeping a history of driver assignmentchanges

The administrative section can also include a control enter (e.g.“FleetMatics/Control Center Preferences”) where a user can setparameters for logging driver hours. For example, the control centercould allow a user to:

Define Start and End of day triggers;

Define Lunch and Break durations; and

Define Benchmarks for Start and End day times.

The administrative section can also include an area for settingreporting metrics, for example in the “Dashboard” (FIG. 3, 320) area,including:

A “Start Time” metric; and

An “Hours Worked” metric with “Overtime” incorporated.

As noted above, in embodiments drivers can also be provided with aTimecard Application configured to allow a driver to input and record adriver's work status, such as Punch In/Out, breaks, and lunches. Thatstatus information will be sent to the system for use in Timecardreports. In embodiments where drivers are provided with a timecardapplication, a vehicle identification “Vehicle ID” can be used as inputon the timecard to assignment the driver to a vehicle. Drivers can alsobe assigned a Driver Number that comprises a unique link to the driverassociated with a driver application. The application can be configuredsuch that drivers can add electronic contact information, such as anEmail address, for each driver in order to for example, send the reportsto the driver. A Driver can also be provided with a link to an externalsite for reports as well.

Although vehicle events can trigger a status event for driver statusinformation (e.g.: engine On/Off after a time parameter triggers a LateStart Alert), as the status behavior is driver-based, a user's selectionfor a driver status report is to select drivers that a user wants to runthe report for (as opposed to a vehicle or the current driver of thevehicle). Similarly, the system is configured to account for driverassignment history when determining what vehicle activity is correct forthe driver and time period the report is run for.

In an embodiment driver status information can be included to provideAlerts as described herein, the Alerts including:

A Late Start Alert

An Overtime Alert

An Off-hours Use Alert.

In an embodiment, driver status information can be included in Dashboardand Trending reports and graphics, including reports for:

An Hours Worked metric

A Late Start metric

An Overtime metric.

Examples of Trending and Dashboard reports and graphics in which driverstatus information can be included are described above and in U.S.patent application Ser. No. 13/097,689, entitled SYSTEM AND METHOD FORPROVIDING VEHICLE AND FLEET PROFILES AND PRESENTATIONS OF TRENDS, theentirety of which is incorporated by reference hereby.

Systems and modules described herein may comprise software, firmware,hardware, or any combination(s) of software, firmware, or hardwaresuitable for the purposes described herein. Software and other modulesmay reside on servers, workstations, personal computers, computerizedtablets, PDAs, and other devices suitable for the purposes describedherein. Software and other modules may be accessible via local memory,via a network, via a browser or other application in an ASP context, orvia other means suitable for the purposes described herein. Datastructures described herein may comprise computer files, variables,programming arrays, programming structures, or any electronicinformation storage schemes or methods, or any combinations thereof,suitable for the purposes described herein. User interface elementsdescribed herein may comprise elements from graphical user interfaces,command line interfaces, and other interfaces suitable for the purposesdescribed herein. Except to the extent necessary or inherent in theprocesses themselves, no particular order to steps or stages of methodsor processes described in this disclosure, including the Figures, isimplied. In many cases the order of process steps may be varied, andvarious illustrative steps may be combined, altered, or omitted, withoutchanging the purpose, effect or import of the methods described.

Accordingly, while the invention has been described and illustrated inconnection with preferred embodiments, many variations and modificationsas will be evident to those skilled in this art may be made withoutdeparting from the scope of the invention, and the invention is thus notto be limited to the precise details of methodology or construction setforth above, as such variations and modification are intended to beincluded within the scope of the invention. Therefore, the scope of theappended claims should not be limited to the description andillustrations of the embodiments contained herein.

1. An computer system for dispatching jobs to a vehicle fleet includingat least one computer processor and computer readable storage medium ormedia including computer code and at least one storage device, thesystem comprising: a memory including a database configured to store atleast one record of a job associated with a fleet entity; the one ormore processors programmed perform at least one of: receive GPS eventdata transmitted from at least one GPS device, each GPS deviceassociated with a vehicle, the event GPS event data including locationinformation for the vehicle; associate at least one vehicle with the jobbased on the GPS event data; and provide, for a graphic user interface,an indication of the at least one vehicle to dispatch the job.
 2. Thecomputer system of claim 1, wherein the one or more processors arefurther programmed at least to: provide, for the graphic user interface,the indication of the at least one vehicle in conjunction with a mapshowing the position of the vehicle.
 3. The computer system of claim 1,wherein the one or more processors are further programmed at least to:provide, for the graphic user interface, at least one input interfacefor selecting an action for dispatching the job.
 4. The computer systemof claim 3, wherein the action includes at least one of: assigning thejob to a driver or vehicle, finding a nearest vehicle to a job;reassigning the job to a driver or vehicle; recalling the job;identifying the job as complete; reopening the job; and canceling thejob.
 5. The computer system of claim 4, wherein the one or moreprocessors are further programmed at least to: provide, for the graphicuser interface, a display of at least one criterion for finding thenearest vehicle.
 6. The computer system of claim 5, wherein the at leastone criterion for finding the nearest vehicle includes at least one of:a time criterion and a group criterion.
 7. The computer system of claim4, wherein the one or more processors are further programmed to provide,for the graphic user interface, a display at least one of, for at leastone nearest vehicle to a job: a number of the nearest vehicles; anidentification of a driver associated each vehicle; a distance of thevehicle from the job; a travel time for the job; and contact informationfor the vehicle or driver.
 8. The computer system of claim 7, whereinthe contact information includes at least one of: an indicator showingthe driver has a computer application configured to interface with thegraphic user interface.
 9. The computer system of claim 8, wherein theone or more processors are further programmed at least to: provide, forthe graphic user interface, an assignment action input for assigning thejob to the driver via the application.
 10. The computer system of claim4, wherein the one or more processors are further programmed at leastto: provide, for the graphic user interface, a pop-up display forselecting the nearest driver.
 11. The computer system of claim 4,wherein the one or more processors are further programmed to provide,for the graphic user interface, a display at least one of: a jobidentification; an address for the job; and job a status dropdown. 12.The computer system of claim 4, wherein the one or more processors arefurther programmed at least to: provide, for the graphic user interface,the indication of at least one nearest vehicle in conjunction with a mapshowing the position of the at least one nearest vehicle.
 13. Thecomputer system of claim 4, wherein the one or more processors arefurther programmed at least to provide, for the graphic user interface adisplay of a schedule for at least one job and at least one driver. 14.The computer system of claim 1, wherein the one or more processors arefurther programmed at least to provide interface tool for at least oneof: managing a job type; creating a new job; managing customers for ajob; uploading a job; and editing a job.
 15. A method comprising, in atleast one computer and a computer readable storage medium or mediaincluding computer code: receiving GPS event data transmitted from aplurality of GPS devices, each GPS device associated with a vehicle;associating at least one vehicle with the job based on the GPS eventdata; and providing, for a graphic user interface, an indication of theat least one vehicle to dispatch the job.
 16. The method of claim 15,further comprising: providing, for the graphic user interface, theindication of the at least one vehicle in conjunction with a map showingthe position of the vehicle.
 17. The method of claim 15, furthercomprising: providing, for the graphic user interface, at least oneinput interface for selecting an action for dispatching the job.
 18. Themethod of claim 17, wherein the action includes at least one of:assigning the job to a driver or vehicle, finding a nearest vehicle to ajob; reassigning the job to a driver or vehicle; recalling the job;identifying the job as complete; reopening the job; and canceling thejob.
 19. The method of claim 18, further comprising: providing, for thegraphic user interface, a display of at least one criterion for findingthe nearest vehicle.
 20. The method of claim 19, wherein the at leastone criterion for finding the nearest vehicle includes at least one of:a time criterion and a group criterion.
 21. The method of claim 18,wherein the method further comprises providing, for the graphic userinterface, a display of at least one of for at least one nearest vehicleto a job: a number of the nearest vehicles; an identification of adriver associated each vehicle; a distance of the vehicle from the job;a travel time for the job; and contact information for the vehicle ordriver.
 22. The method of claim 21, wherein the contact informationincludes at least one of: an indicator showing the driver has a computerapplication configured to interface with the graphic user interface. 23.The method of claim 22 wherein the method further comprises: providingfor the graphic user interface, an assignment action input for assigningthe job to the driver via the application.
 24. The method of claim 18wherein the method further comprises: providing, for the graphic userinterface, a pop-up display for selecting the nearest driver.
 25. Themethod of claim 18 wherein the method further comprises providing, forthe graphic user interface, a display of at least one of: a jobidentification; an address for the job; and a job status dropdown. 26.The method of claim 18, wherein the method further comprises: providing,for the graphic user interface, the indication of at least one nearestvehicle in conjunction with a map showing the position of the at leaston nearest vehicle.
 27. The method of claim 18, wherein the furthercomprises providing, for the graphic user interface, a display of aschedule for at least one job and at least one driver.
 28. The method ofclaim 15, wherein the method further comprises providing an interfacetool for at least one of: managing a job type; creating a new job;managing customers for a job; uploading a job; and editing a job.